


Institutional Archive of the Naval Postgraduate School 





Calhoun: The NPS Institutional Archive 


DSpace Repository 


Theses and Dissertations 


2000-06-01 


l. Thesis and Dissertation Collection, all items 


Transparent detection of QOS violations for 
continuous applications 


Polk, Kendal V. 


Monterey, California. Naval Postgraduate School 


http://hdl.handle.net/10945/7814 


Downloaded from NPS Archive: Calhoun 


DUDLEY 
KNOX 
LIBRARY 





http://www.nps.edu/library 


Calhoun is the Naval Postgraduate School's public access digital repository for 

research materials and institutional publications created by the NPS community. 

Calhoun is named for Professor of Mathematics Guy K. Calhoun, NPS's first 
appointed — and published — scholarty author. 


Dudley Knox Library / Naval Postgraduate School 
411 Dyer Road / 1 University Circle 
Monterey, California USA 93943 


























































































































































































































































































- PEERS UC eed. dinde Lo бағар 
m -, icri .... ыы $ 5.9 baba. "PE M Pernt adio cii 
lt, Ee pl "^ — e^. . о LM ИТУ" е bo И ми С. .. то) во: 
m de LIS PN cos . ч LLL M M РР Ctm Hi 
. "^ | ait © o ы LAM н БД. LAETI „se 4 rn. Ч 
Һс О ДД Weno soa OR я = > dem re ма miu t Ка қ 
“мээ 6 эт, = .. e ... М 
ГГ „6. о ТРЕ еы Солис JE > Euer Мао ДО ИЖ RE IE NE * IT et se” ны раа A | 
К tat Pes Н КЕКТІ еее бъчва > a an А ыы cona . lI TI А ОЕ ФО UT MILL MP фото 3 x ч inc APT 
Д ~ oe cm мит. 4 а г РА T Мне ЧЕ 00 е док ааа ЫС 
ее Б lend ААД ERN мы а Ғы Си УРУ" s . қ E D es я Ы . 9 ns - e a . 9109 0. y eo 5 ПИ МИО а 5 
Иа ы-ы e a T TTA фефст 21 15 ъс. Lui dr na T Гуфи "a Mu... er b "omi _ uml ЖҮ LEE UM Nm ' » e ? qe e. 
pt irri ah ел. и f 35: өш E Ч ә оу ө $ ee pof - Б 1.7777 К ча г NE ^ ur и 
итд фр a < ы - Dr A Á q Pe v М > 
р че eg s een, A о = к : e. 0. LINE" е + PAR e Mem 
os "4. 7ч ДЫТ то „тр 4. ET I SET up ы 2 - e 0 "e260 me undi ID lo. MIN EMT misi es ҚУЫҚ te y бар 
> ы LINE :>O > ы Ludi. i Ime . . x n + Ы be a e LT LEE DTP э mos ө у A ее 
ira "рр Суз ач чо а а no. > = . d " A “-. LLL dc N TI 
Сан 255. уон an i Teed Па Re: A 2 E Мағ e... Й O А 
om ehh med. a [lu тұра - (o ramos q. ағ 9^5 
^рш ue и rem 2 2... ua де en А 
es e fr fied ol tae. ад ва И .. т 2-3, 
>e Г М 2. LENT. TS. we ... ГЕ ` 
aan mec A та +, эү М . “eo DES 
é itn a Т . СР i » ө LINE IT PES DEP SPP CN ... ql un 
"ые ыыы» КЫТ?“ Ф е-2-әзееез? *9-4 e v^ a р в N t. "© «бу da EPI "e 9999 об WS] ei chances аа S A 
wt aee о Ч Жк JE PP em Р аа ы г. Poco 0 Е АКТЕ LL ILES Sees 
ed odii a SUT е "" v^ МТ ОИ inen $ 5 = "000 we “y ng АГЕ р а O A HENRI НЕДА 
net Eee че a tee OR р-а Дын н ы-ы tam we .. - М ББ ИЫ КЕТҮ» „мү? ЖТТ 
= s^ .. de ALO e. *9-9 - ДД А MITT . A "эз учы» өм 
mant e aA ots РИ эру 9. vt E В СЕС В Ан 
ан у» үт бен ЫЛ ДОД » Lem PLE te T "HE e “tem, A 
е% Д в „ LN ЕЕ dI = em be 9 0 “in Д LIMITI ..., 
A e АВ ae 1 = » Har. ы 
om «Fe op Fee en grt we » Label Pu T Гү O° Cowes = 
pap rg d м m а be iu de E ira a . че 45 . 
ооо а b ад ie m = ЕА en ( u ut Ou 
o uad 550 . .. н 9 00 М АНЫН БАЛИ ДО А u a eure tan nme, 
кі MERE: Б = d К Мел Кы гы Г", Домна ОТРИ 
Se Ss d Tr еке ее PL 
Р Мо OL cock ce nn; 
9 vind i ол УСА“ A EA A 
e. q. x ya 
ШС E ace СВЕ 
М s A re 
и: м Mid ТОК ПИ уа реге ... 
oes б 
ee „^Ш ы 
6. ЦУ Д 
““4 % . EIE TD tha 
Баси ара Кода ЩО US id HEP 
e ү da СД TS миы EL АРЫ 
а x LN ee 99 А 
e очи Cd ber ro. МАТ ДА че оса iind 
DL does LISTO deb lo uiuo 
PELLE Y В e em. = бта — 
ЖҮ, А ықы ДАЛА ТЫ o Pote. ass 
Y os w- e. во", NNI АА 
e. Ж 
LN STE pe OR = Sun ...» P 0 S Be 
NALE PPM АУ Ты” е 52 e o " АЕ 
. .. CA A sony PTA в ле ыд 
ДА ы . = E Fr eres am су забива pa А 2 A " E E m A 
* 939 BI LPS е +6. Sa. o e. p 2% А. aa 2 .. ^ А .. E % 9.. IL Tr ТРО 
: = E dd US dd a р иеа i ў а г к; Ы O AS s 
bd u ЫШ on Ы E И brem s "AT э ... ы зе Ы discs lb MEUM n sates .« 
2,5 м ОВР б ы An Heg = * * * d* — ase ore ИСК ТЕ ите ЧАД үлгі A . s mo de ee e т P 
LII ГЕТ AN = үү, a”. . EM) LLL 44% ELE эз» „= А EI E АКО ТИХ eiit ui LUE ee 
LU M MC KDE Pe 29-44 „л эз аа. Д5 К — e ~ mo. P =". » . Foo ... A = ors IR 5 Гл DM PM и 
о7о? , . LLL Pn o. e ." е $ >. е B . me 6 ex М 225 А О ЕА Ша Ае ы КОТЛЕТ” $255 
Mni oe sce o- had. ee DII. .. A ри . ге ~o m Mod o m ^ 4 . ЕА Ы ET. А Ма СЕ СУТ 
е. ы СТО LIIS HEEL LE .Ҡ% ° . ea C TI . Б Да А > Ма e м | . ose МЫСА o» к © > чае © 
ridi ELI. rr ee) eto AI O Хит А е. . 2 ЕК М дн And d A MAL a м БИТ 
b xus I I2 “ы. . . LP z otos o ш КУЛТЕ” m РЧА Pn құқы; OR ness ° КЕРЕЙТ зде di ETC Ко 
ЕТИ u е = “~ КИ еы i ^ o 0 5 ча ы ы - М в -. .. > E. 9 LP NE Conect ape Ed Lid = НЫЙ 
O Fre - e 227 LL pi SS Ы y .... О led " dM TT ned del TE = 
AT A A к> u В К б 2... IT E “....... >. ago. uL ^ f 
HAE LL. PO Г ер еи Ы ` ШЕЛ" ..-. =, E ак de "m" n ent ды n x m pa Re S CS uL Tr 
Y... . . = ^+ бот су LIT MEE SM mo >. г Ж е LI = . .. Да MX РА m 4 Е A 
«d "gp е Uere ы тога PT ESO Seen МАЉРОИ 
E " E E B 
Ж ү a 5 р К Mdb JL LP PEN 
e^ wt Y VO E 0. 000000099 AE T 4 үз ^ 9 9-9» 9 
ме ед y a _ > k A A AA м“ 
Ta Жо и rn rt m 
r га „о na ЪТ 
"-. Ум Ж Se жаа 9-2 з-0. %% 2 
L Y A aida Ж-Е. С в " ААА ВА 
E ow sh se o ¿00 IATA Е E 4 рону x а ща erai - АДА en чт ее ТД ГЛ. 
e AS .. OTT . [7 7 Rel LM А ° . өм LE MS E ULL ILI" "ee w 5*9 КЕРЕГЕГЕ 
. .. uu eos 0% „70, e.» . тə © rr “os E ЫТ 5 Сити Ач + E тее уф. FUPCR Le PR, е4 дето rn ААЫА nn remm 
80 8 ы. „м. © © ре | . mo e mod. "э бө 2. ыш. Мы WT TE CIRCE DER YET T [I ETS ey ЕЕ Кита 
РЕС » - Lid adio ы е - ы ЫЗ . . ... 5 [E . o. «o. LU PO А e... o AD MP AA 
Фф ~ з. -— nt m E " IL LUE PTS " E E . s.p . 9 > vg» Lu ergee Y nd AA 
LES — = Li . Ы иде . E ЖЫШ EN LP" ....4.,. oe e. Le atten ае чо овен 
ALME ^ : е . lo MP" H ei a ae . aa s LET IX Л DLL P" 
КЕ a qas t Б gel ot Te . ... ЕС e . o ы ` om. ии nt 3 pn^ АҚЫ га Герена өт 1% АКТ Е 
3 P P LEN I o mu ys MAA AS rw .... . LL o mee ГЫ LEE ы . 99 « . EA fame te " . E S Pr ей P ih 
LE ло. ө * 99. uL EE CN ы A е LE" os os СЕРР vn... РЕ AIDA 
3 [od ., w e 9 9"-9 96. . -e > y о . 0... ee, dun де rS IE ino lp даа. 
ФФ 9 ^» . қыра LL D «бос ос ее. 28%%9- -%; ә .. ,%, CL ok O .. е е 95.9 999. .-) we 
dii. a LIA - ч we “е ee. ө ез % 29.. . Oe oF э * 9 = от ven re РИА : 
Фо Пе dE Pen . [Li о go .. E IL TP ... LI o PI RA NP ue ча fas САД ре o Нн ЫНА Са Feel аі Ш.А td 
JA NE ТЫР” о о о о E Lr T .. E "T A PU P еее оф... ә в 79-%, ө%% 7 5» өзе “Ас. “мос. 
. .. 99 9 эў э ө әш» LI " o ер. оо ДТ ТІПТ os. к. СУ ЖЕТ 
ара v RES о is e ELEME: - Б ОТОС A T ‚эө em... 
» a) .7 . .%% г е nn. LL. AP она AA aan Ява и yA 
>. 4 +з PITT] ull VP lu UIS" ..%. Ei *^ e €» 29 v. ©.. soosoo .... +0 d 
ә ° Ж Ы ? Һа леді J D eet, ...... РР г... г... "өзө. КЕЛҮ CEE Tr Айы Тары 0400 Феза взе ^ 
dea = ы ъд *9 *9 **e uisu оо ооо оз о ГИ АЕ И И И Туя Б ee E АА чо ~-e o ek aki 
е М eoe er ТОЧ назды ДЫЛЫ ПГ М pues E о ета ае . өзі mr coh старае ы; етер Рух nace 
nt * Ы 4“. o. .. — М ооо озь. we me Lt АРЫ ж Див 
"T е “ез а АРЬЕН БЕН re ъ оола а о .. А СИЕ, КОЕ era has RR Е 
. .. E ? LR LM "е > no .. ... -> ИНН а Pre RE 
4... = E . var. af ТЕТІ LA NET 0 on : во CUTEM bro... .. CUTE өэ а ии II nu 00 mu. 
- .. AS EA ae A Е ПВ И НОВО m 2... «es... 
d иа ща а К Y Poo. a © о чье . ЛА” LI 
ыы аа. А7 . * 70 $6099 « m de... 
ЕО Ы [LI LL ө „б оз .. LIT T ИА 
© O's otoo oe КИ та . T E 
а р OR N I ER ра ^. DILE ла ЕР, LENT g 
ы =. ка * *e** es А er . .. > 
.. bd И ТУРЕ ата NL LO ore 4 *o 25 
«+. CTER TETEN с . КЛ [NM E Ld di dic. E C P E ©з ® ө ө = 
в >. 00..0..—- ... в. М АК ЖЕ LENIN e re + 
.. LI PT “oo. = А РТА ее: 
RIT we .“. . Суч mem ES эё 2 $ ето 
= say y е езе AS eve И ИЕ о *ewe ce. 
. . . * .. LI .. . “a и Г] « .. PT t. «os noe Cr) ora ..... 
LI Ы ove . * а .. A .. >» LIS .. 4» эө э = эч "Nm ЭФ ӨӨ ӨӨ ӨТӨ “зоб. оар» Фе оо овпо 
m «4 е we 6 ..-. æ M м Mas ер e... o кж Де. А-ы 
Ы bs A AO A E A 6. C] NO Cae stew о-о о о о оч = E "e 9o. - 
. ..- " - Li А е . E А u. EET .. EI КК 
. 2 . .. “. ГІТ LE o» "e "ee DLE EP е 
. воо во $ [I S .. or РА ба ее Б E 5 жағ 
ышк у, а a C ет и ога ы .. E PA . . | ome 
- . t000 A М MEI eo has . 9s 2 9999.9 »«- » BEALI q” ЫЈ .. Аа ЕА 
- 25 em e ro duo. E b E .. -— че же. e 5 Lasa asar a “aora or RPM 
.. > * oc L] е .-....,. . LI РЕЯ P = ¿ae РЕТ ° Cano С қатса ал n» - Et 
" М * € Жаса” E . ee ЫЛ . LI rne А ee ER AA P ...... Алг Ааа” vey 
д P = я е в, А n ә... ces ..... Р зори ло ө .... 
< № as б Т Sr ЕЕ er zv к Nos X LU. 
o. М LJ . ° LI . . ° ° » ee M 2» i MT P P . ... LAE Ыйы 
> к A у с M А и г ы СТ ed E о 6 
. e. (d eee .... Pr "aie E 
oe © Me ec eusnns ee" Ей 
”..-..ш. 
АЖ ТТ 
е. - ee т ы .... 
ss ез... 4; * 929555 - Б Да а 
. .. -..... dus NT eooo one ul ым 
eee ce -* c LJ - . .. LAS ^ - 
. s. . о LI ЛЕТТІ PI .... ° 
... ИВ ДКА E ““““..,.е. mo. ae -- >>. гл гь LEM LIN E LE] 
I 9? » e cot , т.ғ“. EAS е LE EERE RERET E " OE) bed . NS 
i АЯ A ЧЕЗ "а %... ЕЕ АИА +. оло 
ees 00% “e e... A EA .. =e. 
е е e A 1. о "e ron. 
JUNE e РЭС . » oe, 
oo rez . o ШЕ Фе шо аео оо о е 6 ь 
LE m МЕККЕГЕ A 
... Жа КОР .. E e .. e. 
= %0 op.a ЕК] ee иж илири >- LIN E L] 
. еч о - P -" tee - .» .: o . 9-9 5. LAE 
“.2.- ^ . LI E „К er} ... ..... LLLI - Ld E 
. “se. A AA ote Se eee Е prt A E “rue. 08 0 во 
LL « ?-9 99 «9v» су .`.. =. EE 
. * eee 


"925 .. . .»..o . € 
SN A 





e... . . E 2” ЛЛА ес EUNT DEL 
ei ЕР . ... Ж. ЖЕ Ы” ..... Ta 0 0% . ы Ди 
IN D “40%. .» **9 e. . LI NI “au... - ы RI 
вее e. eee «= - жи .... LE . К КҮЛ Ld ° LA Г 
“000. КОРЕ "өэ E оо ох AS . м 
"un. КК ОРАЛ ЫС тет о оао о E .*. 02... К 
.. М ” ee. E B LEE NE Б Л } x 
. б - .. "7... ... E E E . o. - “00... A o>o .... p 
.. O E . LES “oo... ...... be d e a Tr E ET арени “че о .. Е LI 
E o ... .... , E A оо о А * ee «ace "e. .... e 
. . hd e E М II , › ... кк Ке КЪТ .. pS 
ШУ М . * 4 оса о ыл ОҚ ur EP prete ae T - ы гита Н 
"ес. b ох оо [m ° C . . - LJ LI т.е 
. . ” .. М P ... . .... ... ... - LE Zr ZU er A zu ... --. ъв - 
. [E r Pers t.. зе. PLI A E БРЕ .^-^.. EI Б ..... "EI y . 
L] LJ е. E $ ИГҮ td eee ° ез ILLE MS LIE OMM ы co... e 
= оо’. - .. . e$ . . 4 e. .. -.-о оо. * 599 A УС е 
. » .. ... we... ry е = LIT - rm " LI ... Py .. eo = 
е о ГАЈ ii Ы мала... ee . ~ E > е . б . on . + e. . .... MO .L£. uL К Ld 
. ° Ы .. . ® - ох - оо Жи] е .- LIT LL „= LEE NS .. terve . hd 
Ж . eS ew ene е. ° n Лажы E E ooo ее. = 4... bi 
LI . ° LI e... e. .... LI . ° . Мы dom LENA .. .,. M ы 
= ” E . ә . E LI EN .- . as . .. .. ... » M 
Q E ee б LI eoa [LN EE .. g тооч оф а А ПЕСИ - * » e*m 
g . LI LI ги: .. . Ы - Lt e. s .. е ... К РА LATE . 
C ese e = @ ee B . б ° . ГИТ а Ира E б б " LE" . - LI . Ы C 
*. | se а Б LN" б JP > œ E ка аа ША? . 
“ LAE . e . . иж е E . . ee » а . . . ЯР 
E М т . . БЕС . .... dono. . . .-. LI ... ewawe 
.. =. М . .. .. ое оао е. о eee o ” a, . ыы Ды ЛА. я 
eee е. .. ие жи: РЕЗ . Ф«еее = . m ^ ° E .. . . 
and "e . . е . " e oco ЧУЕ . DII | ' 
© ee . ee ... . ... ғ. . а тео о оза . 
Ж. .- eee LI . - т . P - e- "e " . . ы i 
. .. .^ .. . . .. ..,. P "" --— e. -.. Ы . 
© - ы . . .. EI . P е ~e. = LEE ee .. . 
E .. Ы e .” $ e9* ... М E . ә .. . Ы . . hd Ы ° 
» ha . . б . ere ое . .. E ... . P e. AA ar -= t A М . . 
ы . . * LI -9 Li P . ь оо в м . .. О ee 
.. . ee ae өзе . .. о. PN ee + AE А ы а " P - . 
. D . . ee -. А РА E . е «ө» " . . eree’ e 
. ee б LE LES б .. . . .... - ee ... LE ... .. ө i 
. eee = б L] . ° . [ET | . .. . - т- » RA 
.. .or.g М LENS . .. . e. .. . P . s Зи 
. ы LJ . М LÀ .. ы . . ee z a 
Ф. . | ee - .. . LI . . . . ЕЖА ec 9 esf ^ Ы . lay Ld 
. . » E .. . МА #5 еә ... E ы 
. о © o т.о . . A 2 ae - PEN ere . ооо 
E . . М б . ° .. ""- Gor .o A . sae n 
. . «t . е eer e Ж” . ee . е е 
ө э Д LJ е М .. .. О . LJ - 
. » “ 


DUDLEY KNOX LIBRARY 
NAVAL POSTGRADUATE SCHOOL 
MONTEREY CA 93943-5101 











NAVAL POSTGRADUATE SCHOOL 
Monterey, California 





THESIS 


TRANSPARENT DETECTION OF QOS 
VIOLATIONS FOR CONTINUOUS APPLICATIONS 


by 
Kendal V. Polk 


June 2000 


Thesis Advisor: Cynthia Irvine 
Second Reader: Timothy Levin 





Approved for public release; distribution is unlimited 





осоЕ КЕЯ аще 
қал жстс 00 
= T 


- = 
за"; - і 
4 "а! 1 өл; --.? 


E — == EI ГЕЛ = = = 


REPORT DOCUMENTATION PAGE Form Approved OMB No 0704-0188 


Public reporung burden for thus collecuon of information 1s estimated to average | hour per response, including the ame for reviewing instruction. searching exisung data 

| sources, gathenng and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other 
aspect of tus collecuon of mformainon, mclodme suggestions tor reducing this burden, tv Washington Headgquaners Services, Directorate for intonation Operations afd 
Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0703-0188) 
Washington DC 20503 


AGENCY USE ONLY (Leave blank) р КЕРОКТ ПАТЕ . REPORT TYPE AND DATES 
June 2000. COVERED 
Master's Thesis 


4. TITLE AND SUBTITLE Transparent Detection of QoS Violations For . | FUNDING NUMBERS 
Continuous Applications 


6. AUTHOR(S) Polk, Kendal V. 


PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) . PERFORMING 
Naval Postgraduate School ORGANIZATION 
Monterey CA 93943-5000 REPORT NUMBER 


SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSORING/ 
MONITORING 
AGENCY REPORT NUMBER 


11. SUPPLEMENTARY NOTES The views expressed in this thesis are those of the author and do not reflect the 
official policy or position of the Department of Defense or the U.S. Government. 


12a. DISTRIBUTION/AV AILABILITY STATEMENT 12b. DISTRIBUTION CODE 
_ Approved for public release; distribution 1s unlimited. 


13. ABSTRACT (maximum 200 words) Resources Management Systems have the task of determining the structure, 
resource allocauon, and scheduling of applications within their scope. One such system is the Management System for Heterogeneous 
Networks (MSHN) which uses its Client Library to gather knowledge of its environment. The Client Library is wrapped around each 
application to gather application status and resource usage information by intercepting and interpreting system calls. In previous work, 
the Client Library was utilized to provide status of an application at the end of the application’s execution. This research focuses on a 
method to gather QoS information on continuous applications within mission-critical systems, while applications are running rather 
than after execution, without modification to the application's source code. 

The Client Library has been modified to provide application execution information that is evaluated and compared against 


user-defined specifications. Any QoS violations result in a notification. This is an indicator for MSHNs scheduler to take corrective | 


action such as adapting to use different resources or data formats. 
When wrapped appheations are used in eonjunetion with continuous monitomng, overhead is inercased, which may be aeceprable 
if transparent QoS monitoring 15 еззеппа|. 


14. SUBJECT TERMS Quality of Service, Resource Management System, Desiderata, MSHN, Wrapper, . NUMBER OF 
QoS Violations, Client Library, Resource Monitoring PAGES 122 


| PRICE CODE 
17. SECURITY CLASSIFICA- . SECURITY CLASSIFI- 19. SECURITY CLASSIFICA- . LIMITATION 


TION OF REPORT CATION OF THIS PAGE | TION OF ABSTRACT OF ABSTRACT 


Unclassified Unclassified Unclassified UL 


NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89) 
Prescribed by ANSI Std. 239-18 298-102 





| 





Approved for public release; distribution is unlimited 


TRANSPARENT DETECTION OF QOS VIOLATIONS FOR CONTINUOUS 
APPLICATIONS 


Kendal V. Polk 
Captain, United grates Army 
B.S., United States Military Academy, 1990 


Submitted in partial fulfillment 
of the requirements for the degree of 


MASTER OF SCIENCE IN COMPUTER SCIENCE 
from the 


NAVAL POSTGRADUATE SCHOOL 
June 2000 





-HOOL 


ABSTRACT 

Resources Management Systems have the task of determining the structure, 
resource allocation, and scheduling of applications within their scope. One such system 
is the Management System for Heterogeneous Networks (MSHN) which uses its Client 
Library to gather knowledge of its environment. The Client Library is wrapped around 
each application to gather application status and resource usage information by 
intercepting and interpreting system calls. In previous work, the Client Library was 
utilized to provide status of an application at the end of the application’s execution. This 
research focuses on a method to gather QoS information on continuous applications 
within mission-critical systems, while applications are running rather than after 
execution, without modification to the application’s source code. 

The Client Library has been modified to provide application execution. 
information that is evaluated and compared against user-defined specifications. Any QoS 
violations result in a notification. This is an indicator for MSHNs scheduler to take 
corrective action such as adapting to use different resources or data formats. 

When wrapped applications are used in conjunction with continuous monitoring, 
overhead is increased, which may be acceptable if transparent QoS monitoring 1s 


essential. 
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I. INTRODUCTION 


Determining whether distributed, real-time applications, such as those for 
Command and Control, need to be re-scheduled or re-configured for different resource 
allocations requires that a resource management system (RMS) quickly detects, or better 
yet predicts and reacts to predicted violations of Quality of Service (QoS) requirements. 
Current resource management systems require that the source code be modified to report 
such violations to the RMS. Unfortunately, this often precludes introducing Commercial 
Off the Shelf (COTS) or legacy software into such systems, even if the COTS or legacy 
algorithms are superior, because source code is either not available or would require a 
very expensive license. This thesis examines an approach for detecting QoS requirement 
violations in Resource Management Systems (RMS), which does not require source code 


access or modification. 


A. BACKGROUND 
1. Quality of Service (QoS) 


QoS 1s a term used by many research groups in many different contexts. Before 
defining QoS, a definition of service 1s necessary. "Service is work done on behalf of 
someone, whom we denote as a client."[CHAT98] For example, an end-to-end 
communication application is a service executed for the end user. This service can be 
executed to varying degrees of quality. Quality of Service is the functionality that a 


client receives from a service executed at a given level of quality. The client receives a 


certain level of functionality if the service provides a certain level of quality. Service 
specific, QoS parameters define this level of quality [CHAT98]. 

QoS parameters or specifications can be grouped into metrics or policies. Metrics 
specify QoS parameters that are quantifiable, whereas polices define system actions based 


upon system state. The following chart presents a sample QoS hierarchy: 


QoS Specifications 


u 


Metrics Policies 
7 | ай Relati | M 
elative SR anagement 
Security Performance Importance rn Policies 


at ae 


Timeliness Precision Accuracy Combinations 


Figure 1. QoS Specification Hierarchy [CHAT98] 


Normally when researchers discuss QoS they focus on performance metrics. 
Timeliness is generally a representation of the time required to execute a given piece of 
work. Example timeliness parameters are total time (begin to end), start time 
(earliest/latest) for a task, and deadline (earliest/latest) for a task to complete. Precision 
relates to data volume quantities, and can be represented as the precision of content for 
input and output data, and the representation for input and output data. Errors introduced 
into data by a service define accuracy. Accuracy parameters relate to the content for 
input and output data and to the representation for input and output data. 


[CHAT98][CLARK98] 


24 Commercial Off the Shelf (COTS) 


Government policies have recently undergone a change with respect to the 
acquisition of computer systems. There has been a shift in the DoD to evaluate the use of 
COTS products in a new system prior to its development [SLED98]. The rising costs of 
system development and shrinking budgets necessitate the interest in less costly COTS 
technology. "In systems where the use of existing commercial components is both 
possible and feasible, it is no longer acceptable for the government to specify, build and 
maintain a large array of comparable proprietary products.” [SLED98] 

Government procurement requires precision to ensure cost effectiveness and 
interoperability. COTS are referred to as "commercial items" under the Federal 


Acquisition Regulations (FARs) [FAR 96] and follow these general characteristics: 


° exists a priori, 
е available to the general public, and 
е can be bought (or leased or licensed) [OBER97] 


Those implementing systems using COTS components must realize that there are 
issues with system distribution, interface standards, and legacy system reengineering that 
affect a COTS-based distributed implementation. Supportability over the equipment or 
software's lifetime is also a key issue and must be analyzed on a case-by-case basis. 
"Each system or equipment must be scrutinized more closely than MIL-SPEC programs 


because of the dynamic commercial infrastructure, and technology turnover." [VIRT98] 


There are seven major documents that guide the federal government, and 
especially the DoD, on the use of commercially available information technology 
products. Their focus on the use of commercial IT products are summarized as follows 


[OBER97]: 


e  Clinger-Cohen: “increase acquisition and incorporation of commercial 
technology” 


е FAR: “acquire commercial and nondevelopmental items (C/NDI) when 
available to meet the needs [of the program]" (The FAR also requires primes 
and subcontractors at all tiers to incorporate C/NDI to the maximum extent 
practical.) 


е DoD 5000.1: “If use or modification of existing...equipment will not meet the 
need, give top priority to...commercially available equipment." 


• DoD 5000.2-R: “Consider C/NDI [to be] the primary source of supply” 

e Joint Technical Architecture (JTA): “specifies a set of performance-based, 
primarily commercial, information processing, transfer, content, format and 
security standards. 

e Defense Information Infrastructure (DI) Common Operating Environment 
(COE) : “consists of an approach for building interoperable systems; a 
collection of reusable software components; a software infrastructure for 
supporting mission area applications" 

Each of these policy documents has the common thread that they mandate or encourage 


the use of commercial items, standards (non-governmental), technology, and/or best 


practices.[OBER97] 


ài Resource Management Systems (RMS) 


QoS is easy to provide to applications if these applications do not share resources. 
Broadcast and cable TV providers are able to guarantee a certain level of quality of 
service because each channel is assigned a certain frequency (i.e. no resources are 
shared)|CHAT98]. In a computing environment where resources are scarce, a degree of 
QoS is desired, and multiple services utilize these same resources, a resource 
management system is needed. 

"Resource Management determines what service to perform and where and 
when to perform the service[CHAT98].” — What determines the structure of the service; 
where determines which resources to allocate to each service; when determines the 


schedule of how to execute a set of services on a resource. A sample RMS is below: 
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Figure 2. Example Resource Management System 


In this case the client requests a service from the RMS scheduler and, based upon 
the model, which is a database that contains information about the resources necessary to 


execute the service (what and where), the scheduler determines when to execute this 


service based upon current resource status and QoS parameters. Once execution has 
begun the task handler provides feedback to scheduler and the model to enact any 


necessary schedule changes. This 1s known as adaptive resource management. 


B. MOTIVATION 


The research performed in this thesis provides a basis for efficient QoS 
measurement in a distributed, heterogeneous computing environment. Specifically, this 
thesis research will focus on identifying the following: QoS requirements in this type of 
computing environment, the data that need to be captured/sent to a QoS measurement 
mechanism, and the use of this data to detect violations of these requirements by COTS 
applications. QoS violation detection techniques that can be applied to a broad range of 
software will allow more COTS applications to be introduced into future real-time, 
warfighting systems, perhaps enhancing speed and interoperability. 

The DARPA-sponsored Management System for Heterogeneous Networks 
(MSHN) project, currently underway at NPS, is a subcomponent of the DARPA 
QUORUM program. The goal of this project is to provide Quality of Service (QoS) for 
both operational and planning applications that are able to use multiple sets of resources, 
while accounting for priorities and environments that change dynamically. The RMS for 
MSHN is equipped with algorithms to maximize overall benefit rather than benefit to a 
particular user. Thus an individual may not get everything he wants, 1.e. “ideal”, but may 
get “pretty good” instead. Currently, most systems implement QoS violation detection by 


directing that the monitored applications pass messages to the RMS. This method is not 


applicable to COTS or legacy software that cannot be retrofitted to pass these types of 
messages. Techniques must be developed to detect and report QoS violations without the 
modification of source code. We call this transparent detection of QoS violation. The 
MSHN CL was developed to provide such transparent detection. However, CL only 
measures QoS at the end of a user's application. This has two problems. First, an RMS 
does not have the opportunity to adapt if QoS information is received after task 
completion. And second, this mechanism cannot be used with tasks that run continuously 


(e.g. sensor tasks). 


C. SCOPE OF THE THESIS 


This thesis research focuses on the transparent detection of QoS violations to 
enable timely system re-configuration (adaptation). Initially, QoS requirements for real- 
time, distributed applications will be identified and characterized based upon user criteria. 
Secondly, an experimental analysis of transparent QoS detection overhead and timeliness 
wil be performed on the continuously executing DynBench applications from the 
Desiderata RMS. Conclusions generated from the analysis will give focus to future 


experiments and modifications of current techniques for QoS detection. 


D. ORGANIZATION 


Chapter II discusses the QoS requirements of a real-time distributed system with a 
focus on the applications Desiderata and AEGIS. Chapter III presents current Resource 
Management tools and a detailed overview of the MSHN project. Chapter IV describes 


the modification to MSHN's monitoring library that will enable dynamically adaptable 


QoS violation monitoring. Chapter V discusses the experiments conducted to determine 
the timeliness and overhead of this approach to QoS detection. Conclusions from this 
thesis research and suggested future work that this research may lead to are described in 


Chapter VI. 


И. REAL-TIME, DISTRIBUTED APPLICATIONS 


This chapter gives an overview of real-time, distributed applications and their 
QoS requirements. Section A focuses on the AEGIS system, its components and 
functions. It will analyze the system progression and applicability to command and 
control situations. Section B focuses on the Desiderata project, its application to real- 
time distributed systems, and its use of dynamic paths. Section C presents and analyzes 


the QoS requirements of real-time distributed applications. 


A. AEGIS 


An early example of a real-time distributed application is the AEGIS Weapon 
System developed for the United States Navy in the 1970’s. Its purpose is to defeat 
hostile anti-ship cruise missile technology. Its search and track space envelope covers 
over 100,000 square miles. It utilizes a network operating system that allows its four 
main systems to “talk” to one another to detect, track and engage targets. The systems are 
(РЕКК98): 

e Command and Decision Module-- Interface between man and machine. 
е Weapon Control System-- Controls the processes that engage weapons. 
e Radar System--Controls radar to search for and track/evaluate targets, missiles. 
e Display System--- Supports Large Screen Display processing. 
For a detailed description of all components see [PERI98]. The following is a graphical 


representation of how the systems interact: 
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Figure 3. AEGIS Architecture [PERR98] 


As this system approaches its third decade, developers are attempting to integrate the 
computing advances that have occurred since its inception. Faster hardware, networks, 
and targets have required developers to modify current scheduling algonthms and 
software to take advantage of real-time, heterogeneous computing environments. 
Determining and implementing these modifications are not problems specific to the U.S. 
Navy but to all of the DOD, which is why projects are being funded throughout the 


country to address them. One such project is Desiderata. [DESI98] 
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B. DESIDERATA 
le Overview 


Desiderata is focused on the development of next-generation, distributed systems 
for combat. These types of systems have strict QoS objectives. They must contain some 
underlying mechanism enforcing a reliability policy, react to threats in a timely manner, 
and always be available in hostile environments. Resource usage must be efficient and 
scalability must be possible to “address the ever-increasing complexity of scenarios that 
confront such systems [DESI98]." To provide QoS, Desiderata focuses on the following: 

e QoS Specification 

e QoS metrics 

е dynamic QoS management, and 

е benchmarking 
The name Desiderata is derived from its applicability to Dynamic, Scalable, Dependable, 
Real-Time systems. Desiderata is a testbed project for the US Navy to enhance QoS 
management technology in a shipboard distributed computing environment. This 
technology includes its own specification language and QoS management programs that 
Support dynamic path-based systems. During application execution the QoS management 
system benchmarks application information which is used to facilitate resource 
management. 

2: Dynamic Paths 

A dynamic path is an entity used in Desiderata's QoS assessment to identify the 


start and end point of a series of connected actions. Each action is usually performed by a 


separate application. These paths may have resource or timing constraints that are used to 
determine adherence to QoS specification. As with many air defense type systems, 
Desiderata begins with the threat assessment path. These actions include sensor (radar) 
input, filtering, filter management, and evaluation. The information passed along the path 
is considered dynamic because the sensor’s input may range from a few to several 
thousand tracks and cannot be determined in advance. This type of path is classified as 
"continuous" because it is in constant operation [DESI98]. Normally there will be some 
timeliness requirement determined for the end-to-end latency of processing one set of 
sensor input. 

The next path begins once the threat assessment path determines that there is a 
potential threat and an action against that threat is necessary. This type of path is called 
"transient" because it is invoked in response to sensor input. [DESI98] Time is also a 
critical factor in this path. The path latency objective is key in these types of systems 
since they may involve mission-critical or safety-critical operations. Desiderata refers to 
this as the engagement path, 

The final path is the missile guidance path, which is “activated by an action 
initiation event and deactivated upon completion of the action. [DESI98]" Since this path 
behaves like a continuous path once it becomes active, it is called “quasi-continuous”. 
Once the system fires a missile (activated), it will continually give guidance commands to 
that missile until it explodes (deactivated). The characteristics (speed, distance, altitude) 


of the threat cause the iteration time of a cycle to be dynamically configured. 
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2; Svstem Architecture 


Actions in the dynamic paths (real-time paths) send time-stamped messages to the 
QoS metrics component. This component then calculates whether the path-level QoS 
metrics are being met and sends this information to the QoS diagnosis component when a 
violation is detected. The diagnosing component advises the action selection component 
of the cause of the poor QoS and recommends actions such as moving to a different host 
Or program replication to improve QoS. The action selection component determines the 
best of the recommended actions to execute. The allocation analysis component 
determines a suitable way to allocate resources for these actions by consulting the 
resource discovery for local area network (LAN) hardware metrics. This component 
then requests the allocation enactment component to execute these actions. At heart of 
this architecture are the spec files which contain path latency requirements, startup LAN 


and Host resource specifications (e.g. SPARC, Windows® NT, 200Mhz), resource 


locations, and real-time path designations. See Figure 4. 
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Figure 4. Logical architecture management software [DESI98] 


Desiderata’s system architecture is displayed as follows in Figure 5: 
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The Resource Manager 15 activated when the dynamic paths are not meeting time 
constraints and when applications terminate abnormally. Resources are reallocated based 
upon these events to improve the QoS metrics of timeliness and fault tolerance. The 
Program Control component requests daemons on particular hosts to start and stop 
applications based upon mandates of the Resource Manager. Another function of the 
Program Control is to receive abnormal program termination information relayed to it by 
startup daemons and forward this information to the Resource Manager. The Startup 
Daemons reside only on one host and control applications’ starts and stops. The 
Hardware Monitor is a daemon that resides on each host and is responsible for gathering 
load metrics for hosts and the LAN. It then passes this information to the Hardware 
Broker. The Hardware Broker collects all the monitors’ metric information and develops 
an aggregate load index for each host, which is sent to the Hardware Analyzer - a 
component responsible for providing a sorted list of host load indexes. The QoS 
Manager(s) “detects if a real-time application path becomes unhealthy (misses its 
deadline), diagnoses the cause of the poor heath, and suggests corrective action (such as 
moving or replicating an application program) to the resource manager [DESI98]." The 
System Broker provides clients with information from the system specification and the 
Name Server maintains information on middleware application configuration. The final 
component of this system is the QoS Management Human Control Interface (HCI) that 
provides information to the user regarding configuration of the system, status and QoS of 


applications, and resources’ reallocation operations. [DESI98] 


C. QUALITY OF SERVICE REQUIREMENTS 
1. Overview 


To best maximize the use of existing resources, QoS metrics and monitoring are 
essential to resource management. An RMS must know the system's current status and 
the level of service it is responsible for delivering to the client. In a dynamic, combat 
environment, computing technology must be as adaptive as the soldier, and maintain 
situational awareness to execute mission-critical tasks. Though QoS specifications can be 
divided into policies and metrics, the performance metrics of timeliness, accuracy, and 
precision are best suited for the mission-critical and safety-critical systems used in 
military conflict [CHAT98]. 

25 Timeliness 

Timeliness encompasses a class of metrics that measures time-related entities. It 
can be defined as a “representation of the timing requirements for performing a given 
piece of work [CHAT98].” Timeliness metrics are often quantified as latency, delay, or 
time to complete. They may also represent the earliest or latest start time for a task. For 
time-critical systems, timeliness is used synonymously with the term deadline. Failing to 
achieve a deadline in these types of applications may at a minimum, render collected data 
useless. At a maximum, it could result in the loss of life. In air defense systems utilizing 
the dynamic path paradigm, sensor data in the threat assessment path must be transferred 
to the engagement path. Also sensor data are given to the missile guidance path. The 
RMS must control the “timeliness” of these actions to ensure system synchronization, and 


threat detection and destruction. 
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3. Ассигасу 


The measure of data correctness and errors introduced into data by work and 
services performed define accuracy. [CHAT98] There must be a distinction made 
between data content and representation as the data flows through an application. 
Content refers to the accuracy of the data, whereas representation refers to the accuracy of 
the data's representation to the computer. If data generated at a certain level of accuracy 
cannot be depicted within the computer with that same level of accuracy, then 
applications lose the benefit of the data's initial correctness. Accuracy is especially 
important for an RMS in military applications because it is the responsibility of the RMS 
to “sell” information to its clients — decision-makers and operators. [CLAR97] In a 
manual system, inaccurate data can cause these clients to make uninformed and 
potentially disastrous decisions. In a system utilizing automated engagement, there 1s no 
"human factor" to aid in decision making, so inaccurate data will possibly cause the 
system to give an improper response. 


4. Precision 


Precision is also defined as it relates to content and representation. Precision of 
representation refers to the amount of data or work (volume)[CHAT98]. This volume ıs 
the physical amount of bits and bytes. The more bits used to represent a number, the 
greater number of decimal places are available for more precise calculations. To clarify 


the difference between accuracy and precision refer to Figure 4. 
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Figure 6. Precision vs. Accuracy 


Using the ISO/OSI model, the precision of content in one layer translates into a 
precision of representation in the next lower layer. For example, a data packet in the 
network layer is composed of the payload and the header (content); the content of this 
data structure is understood by the network system. But the lower datalink layer 
recognizes that data only as a collection of data bytes and represents that as a series of 
bits. [CHAT98] The precision of representation affects how well the information can be 
read in the network layer of the destination host. 

Аш defense monitoring systems refer to precision as Track Quality (TQ). 
[CLAR97] TQ is calculated from sensor input and incorporated in the current track 


record. The TQ is then updated based on these calculations until the TQ (or precision) 
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drops to unacceptable levels and then the track is dropped. This is an example of how a 


RMS uses the precision metric in threat monitoring. 


D. SUMMARY 


Chapter ll gave an overview of real-time, distributed applications and their QoS 
requirements. Section A focused on the AEGIS system, its components and functions. It 
analyzed the system’s progression and applicability to command and control situations. 
Section B focused on the Desiderata project and how it applies to real-time distributed 
systems. It discussed the use of dynamic paths for QoS assessment and resource 
allocation, and how Desiderata could be used to further automate these actions. Section 
C presented and analyzed the QoS requirements of real-time distributed applications and 
how they can be measured. The QoS requirements were Timeliness, Accuracy, and 
Precision. The next chapter will discuss current RMS projects with a focus on MSHN 


and its relation to Desiderata. 
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ПІ. RESOURCE MANAGEMENT TOOLS 


Resource Management Systems (RMS) are commonly referred to as meta- 
computing systems though they actually build on top of the metacomputing framework. 
The RMS goal is to provide a prescribed quality of service (QoS) to processes and 
applications that are competing for distributed, heterogeneous resources [HENS99]. А 
RMS parallels the execution of a distributed operating system in that it views the group of 
computers it manages as a virtual machine [VAN 85] and attempts to provide the user 
with a "location-transparent" view of the resources. Through the use of a RMS, users 
should gain a higher level of resource availability and fault tolerance than would be 
possible on their local system alone [HENS99]. A RMS does not manage the resources 
of each computer, which is why it differs from a distributed operating system. The RMS 
is responsible for monitoring application, resource and QoS status across the virtual 
machine, and issuing commands to facilitate keeping those statuses at prescribed levels. 

Chapter Ii discusses three on-going RMS research projects, their architectures 
and areas of focus. Section A details the GLOBUS [CZAJ97] project and its attempt to 
provide innovative resource management solutions. Section B provides an overview of 
the ERDOS [CHAT98] project and its resource management approach. Finally, Section 


C details the MSHN [HENS99] project as an adaptive QoS-driven RMS. 
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A. GLOBUS 


Each attempt to 1mplement resource management of geographically distributed 
resources begins with an identification of the problems to be solved. The GLOBUS 
project has identified five key elements of resource management that are addressed in its 
architecture. 

e First, since resources are owned and operated by different organizations, in 
different domains, it is unlikely that there will be commonality in policies 
such as acceptable use, security, and scheduling. This is known as the site 
autonomy problem. [CZAJ97] 

e Because each site is autonomous, it can be expected that each will use 
different local RMS or if the same RMS is used, it will be in a different and 
possibly incompatible configuration. This is called the heterogeneous 
substrate problem.[CZAJ97] 

e The third problem is policy extensibility, which arises because heterogeneous 
distributed computing applications come from a wide range of domains with 
different resource requirements. Thus a RMS "must support the frequent 
development of new domain-specific management structures, without 
requiring changes to code installed at participating sites[CZAJ97]." 

e Because some applications have requirements that can only be met though the 


use of several resources simultaneously, the fourth problem is co-allocation. 
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e The final problem of online control is very closely tied to QoS. In a RMS, 
negotiation is necessary to ensure that applications can adapt to resource 


availability, especially when requirements and resource status are dynamic. 


GLOBUS’ architecture was designed to address the five problems mentioned 
above. Entities known as resource managers confront the problems of heterogeneous 
substrate and site autonomy. The managers provide a well-defined interface to different 
local resource management tools, policies, and security implementations. The project has 
a resource specification language (RSL) that, in conjunction with resource brokers, 15 
able to support negotiation between different components of a RMS, and handle 
application requests. These components address the problems of online control and 
policy extensibility. Resource co-allocators define various co-allocation strategies to 
defeat the co-allocation problem. Figure 5 presents the GLOBUS architecture. In this 
diagram, LSF, EAS Y-LL and NQE represent local resource schedulers and GRAM is the 
local resource manager. Key to this architecture is the information service. It is 
responsible for providing information about the current availability and service 
capabilities of resources. This information is used to: locate resources, determine 
resource properties, and process high-level resource specifications into specific manager 
requests [CZJA97]. A testbed for this architecture was developed that is comprised of 15 


sites, 330 computers and 3600 processors [CZJA97]. 
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B. ERDOS 


Figure 7. The Globus resource management architecture, 
showing how RSL specifications pass between application, 
resource brokers, resource co-allocators, and local managers. 
[CZJA97] 


The End-to-End Resource Management of Distributed Systems (ERDOS) project 


15 an architecture developed to provide adaptive, end-to-end, and scalable distributed 


resource management to applications [CHAT98]. This is a difficult goal to achieve 


especially in a distributed environment where real-time resource requirements dictate 


coordinated resource management. The problem is intensified by today’s heterogeneous 


computing environment, high degree of resource sharing (GLOBUS’ co-allocation 


problem (CZJA97]) with. varying QoS requirements, and a computing domain where 
resource availability and requirements are dynamically changing. [CHAT98] 

The goal of ERDOS is to “identify the functions that must be preformed by each 
of the system layers in order to achieve end-to-end application-level QoS guarantees by 
performing QoS-driven resource management [CHAT98].” The ina models capture 
information from the three perspectives (application, resource, and system) of resource 
management and enable the middleware to react to heterogeneous applications and 
resources:[CHAT98] 


e Logical Application Stream Model (LASM): Application perspective — 
determines applications” structure in a system-independent manner. 


e Benefit Function (BF): - An abstraction that models an application’s QoS 
stipulations and preferences. 


ө Resource Model: Resource perspective — captures the resource information 
necessary for resource management algorithms. 


e System Model (SM): System perspective — describes the layout and 
management structure of system resources. 


ERDOS identifies the system layers as application, middleware, and resource. The 
architecture 1s not limited to proprietary applications or specific algorithmic policies. To 
facilitate communication between these layers, application programmer interfaces (APIs) 


are used. See Figure 8. 
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Figure 8. ERDOS System Architecture [CHAT98] 


There are two primary API’s in this architecture. The first API, the LASM-BF 
API, is between the middleware and the applications. The API facilitates the resource 
manager controlling the components of applications by determining on which resources 
the applications should run and at what level of QoS. This interface allows applications 
to run on different QoS-driven systems, independent of the RMS middleware 
implementations.[CHAT98] 

The second API, the Resource Model API between the middleware and the 
resources, divides the middleware into generic and resource-specific parts. This division 
allows for masking of implementation details of resources from the middleware, and 
dealing with all resources in a uniform manner. The second point is especially important 
because it simplifies integration of new resource types.[CHAT98] 


e The ERDOS middleware QoS architecture is shown in Figure 9 [CHAT98]. 
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Figure 9. ERDOS Middleware QoS Architecture [CHAT98] 


The middleware of this system encapsulates the crucial adaptive RMS algorithms 
that assign resources to applications, schedule applications on the shared resources, and 
adapt an application's QoS when system requirements exceed resources. The use of APIs 
provides portability to the system, which allows for the use of COTS software at the 
application, and resource layers. The adaptive nature of the RMS makes this system 
useful in a mission-critical or time-critical computing environment when QoS 


requirements are in conflict with system resources available. 


C. MSHN 


Another RMS envisioned for a heterogeneous computing environment 15 Ше 
Management System for Heterogeneous Networks (MSHN). The goal of MSHN, as with 
any real-time RMS, is to identify current resources available in a computing domain and 


allocate those resources to applications. Resource allocation mechanisms attempt to 


D 


provide a predetermined QoS to these applications based upon factors such as security, 
user preferences, and timeliness requirements. [HENS99] 

MSHN ıs intended to be a research system to develop adaptive scheduling of 
process execution and provide support for adaptive-aware applications [HENS99]. 
Adaptive—aware refers to the ability of an application to input, process or output data in 
different versions based upon QoS metrics such as precision, accuracy and timeliness. In 
addition to resource allocation, MSHN's model describes adaptive mechanisms to allow 
for application migration from one system to another, ıf QoS violations are above ап 
acceptable threshold. 

“MSHN seeks to determine how to meet multiple different QoS requirements to 
multiple different applications simultaneously [HENS99].” There are two key issues that 
must be addressed in order to achieve this objective. First, a method must be developed 
to dynamically determine a value for a combination of QoS requirements. Second, 
resource allocation algorithms must match applications to resources that best achieve this 
value. 

When a user requests service, a RMS should transparently locate resources in its 
computing domain to provide the service. The user should no be required to explicitly 
request the RMS to perform its task. | MSHN's architecture (see Figure 10) provides for 


both while also addressing its objective's key issues. 
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Figure 10. MSHN Conceptual Architecture [HENS99] 


Central to MSHN’s execution is the Client Library. The Client Library provides a 
mechanism for executing remote processes and for transparently determining the 
computing domain’s resource status. The Client Library is “wrapped” around an 
application and intercepts that application’s system calls [SCHN98]. Researchers at the 
University of Wisconsin refer to this action as Process Hijacking [ZAND97]. This 
technique is used for the RMS to gather application/process information on COTS 
software not designed to report to that RMS. A MSHN Daemon runs on each system to 
Start processes on behalf of the Client Library. 

The Scheduling Advisor’s (SA) task is to make a best effort allocation of 
resources to applications. To achieve this, it receives information from the Resource 
Status Server (RRS) and the Resource Requirements Database (RRD). The RSS 
maintains a database of static, moderately dynamic, and highly dynamic resources. The 


RRD is a database that provides to MSHN a list of the resources necessary to execute 
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applications at their desired QoS. These components communicate with each other and 
are updated constantly to ensure proper operation of this RMS. Specifics of component 


execution and communication will be discussed in the following chapter. 


D. SUMMARY 


Chapter III provided an overview of three on-going RMS research projects, their 
architecture and areas of focus. Section A provided information on the GLOBUS project 
and its attempt provide innovative resource management solutions. Section B gave an 
overview of the ERDOS project and its current application towards resource 
management. Finally, Section C reviewed the MSHN project as an adaptive QoS-driven 
RMS. Chapter IV will analyze QoS status monitoring and QoS violation detection. The 


Desiderata and MSHN RMS projects will be used as case studies for this analysis. 
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IV. QOS VIOLATION MONITORING 


Desiderata and MSHN are both QoS-driven RMSs that require QoS monitoring to 
effectively allocate resources. “Effectively”, in this case, means best effort execution of 
an application to a user’s requested and required QoS. Best effort execution gives the 
same priority to all applications, therefore, when the load is low, the RMS can deliver 
high-quality service easily. With an increased workload comes a uniform decrease in the 
service-quality levels the RMS is able to provide [HUSTOO]. For example, a user may 
indicate preferences for particular formats for output. A requested level of QoS may be 
streaming video, but if the resources required for video display are not available, then a 
text based representation may meet the QoS requirement. Although the user might not 
receive the most preferred format, the RMS working with the adaptable application is 
able to adjust and provide some level of service as opposed to none. In contrast, if the 
RMS is working with an application that is not adaptable, then QoS depends upon 
successful completion of the application. In a mission-critical system, where the key QoS 
metric is timeliness, the requested and required levels of QoS are synonymous. It is 
imperative that the RMS identify QoS violations, and react appropriately — for example, 
by migrating or by distributing processes to other hosts, or decreasing precision - so that 
requested and required levels can be met. 

In this chapter, QoS violation monitoring techniques of RMSs will be reviewed. 
Section A presents the Desiderata process for monitoring QoS and detecting QoS 


violations. Section B presents our proposed MSHN QoS violation detection method. 
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A. DESIDERATA 


QoS measurement has a major effect on Desiderata's operation. At the center of 
this measurement is the timestamp. Тһе SendTimeStamp function's structure is as 


follows: 


int SendTimeStamp(int  pathserv sd, //path manager's comm. socket 


char Event[1], //event parameter 

int Sequence, //current sequence number 

int TacticalLoad, //number of tracks-datastream 
char Host[32], //name of host of application 
char ID[S], //process identification 

int buffsize) //size of buffer or message size 


This function is used to send a message to the Path Manager that conveys the current 
mode of an application. Pathserv sd identifies the socket that applications should use to 
communicate with the Path Manager. The Event parameter takes the values of "R", "S", 
and "D", which signal to the Path Manger that an application is registering, starting or 
done respectively. Other parameters in the structure are the cycle count, host and process 
identification number of the sending program, and the buffer or message size. This 
function's return value indicates to the calling path application whether the Path Manager 
is Dead or Alive. The R, S, and D timestamp data are used by the QoS Manager in 
conjunction with the QoS specifications to determine whether a path is meeting its 
defined level of QoS. [SONAO0] Load and violation information is then passed to the 
Resource Manager, which is responsible for program allocations and actions. These 


actions include spawning multiple versions of the same program or migrating a program 
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to a host with more resources available. Figure 11 displays the information and control 


flow of the Desiderata system. Note the timestamp information flow from applications to 


the QoS Manager. 
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Figure 11. Timestamp Sequencing [DESI98] 


Not pictured are the hosts where these programs are executed. To see how they are 
integrated review Figure 5. Application timeliness information is developed dynamically 


to assist in violation detection. It is compared to static specifications with the following 


Specfile syntax: 
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PATH Guidance{ 
Connectivity( 
(D:B:MGM, D:B:MG); //This defines the path’s flow — Missile Guidance 
Manager to Missile Guidance System 


Type Continuous; //This path is always executing. 
RealTimeQos( 
SimpleDeadline 1.0; // Deadline for path execution 
BatchLatency 5.0; 
BatchInterArrival 5.0; 
Maxslack 80; //Max deviation from deadline 
MinSlack 20; //Min deviation from deadline 
SlidingWindowSize 20; 
Violations 15; //Number of violations before flag is raised 
еїс 


Though this is only a portion of one dynamic path specification in Desiderata, the 
other paths are very similar; the majority of a path's specification is devoted to stipulating 
time parameters such as the deadline and the minimum and maximum slack (deviation 
from the deadline) allowed during a path's execution. Though timeliness is addressed 
extensively, currently there are no aspects of this system that address areas of precision or 


accuracy.[SONAOO] 


B. MSHN 


The vision of the MSHN project is to develop a system that can monitor QoS and 
dynamically manipulate processes and resources within its scope to provide the user with 


a requested level of QoS or an acceptable substitute. MSHN's Client Library (CL) 
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monitors application completion times by trapping the exit system call. The current 
implementation of the MSHN project comprehensively gathers data on an application’s 
resource usage by "wrapping" that application, intercepting its system calls, and storing 
that data. With the monitoring data from these discrete applications, scheduling 
decisions can be made regarding the application termination actions necessary to achieve 
the requested QoS. The intent of this research is to adapt the CL to be able to monitor 
progress of continuous applications (those that do not include the exit system call), while 
Maintaining the ability to evaluate those that are discrete. By adding a component to the 
MSHN system that is able to transparently detect continuous application QoS timeliness 
violations, MSHN will be able to perform its duties as a RMS with a wider range of 
legacy and COTS software. This is in contrast to Desiderata, which uses the 
SendTimeStamp, invoked via explicit function calls within the source code of the test 
applications (i.e., not transparent monitoring) to provide input to the QoS manager. The 


proposed MSHN component is the Transparent Path Monitoring System (TPMS). 


1. Transparent Path Monitoring System( TPMS) 


The TPMS is comprised of the following five modules: 
e SpecDB Module -Specification Database 
e PathDB Module -Path Database 


e Path Tımer Module 
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ə Evaluate and Alert Module 
е Control Module 


The relationship of TPMS modules to MSHN modules is shown in Figure 12. 
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Figure 12: TPMS Representation in Regards to MSHN 


The SpecDB Module is responsible for establishing in memory a database that contains 
path timeliness QoS specifications, which are similar to those used in Desiderata. This 
module parses a user-defined data file, and uses it to populate the database in memory; as 


a memory-resident database, there is fast access to data by the system. The specifications 
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detailed here include path identification number, length and deadline; the application 
identification numbers; and the order in which the application executes within a path. 
Once this module is initialized and populated, the TPMS initiates the PathDB module. 
The PathDB module creates a PathDB database that contains the path 
identification number and path length for each path. It also contains pointers to the 
multiple instances of path status data that a single path may create. There will be a 
separate instance for each datastream. Each instance of that path contains an instance 
identification number, a counter to determine how many applications have reported, and 
an array that holds application initiation and completion times. These times are used to 
calculate path latency. The following depicts the results of PathDB module’s 


initialization phase with one path, one instance and one application report time. 
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Figure 13: PathDB Module Initialization 
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In this case, pathLength and appCounter all have the value of . Instances of a path are 
created as necessary to accommodate application time data as they arrive. These times 
are placed in a dynamic array built at runtime. Its size is based upon the number of 


applications in a particular path. Because the applications used in this research are queue- 


based there is a possibility that a new timestamp for a single application may arrive at the 


57 


Control Module even though the prior path has not yet completed; therefore, multiple 


instances of the same path are supported. For example: 













|l d iili. Application 1 delivers timestamp Stored in 1" instance of Path A 
Application 1 delivers timestamp Stored in 2" instance of Path A 
Application 2 delivers timestamp tored in 1* instance of Path A* 


Sequence of Action Result 
Events (Path A = Apps 1, 2, 3) E 


Table 1: Timestamp Sequencing 


The assumption made in sequencing is that there 1s no possibility that a datastream passed 
to application 2 by the 1* instance of application 1 could be superseded by the datastream 
from the 2” instance of application 1. Note that if you could show where the queue 
bottlenecks, then that particular element of the path would be a candidate for 
parallelization. 

In the Evaluate and Alert Module, the Total Path Time (TPT) is compared to the 
deadline information stored in the Specification Database. If the TPT exceeds the 
specified deadline, then a flag is raised. It is then the responsibility of the MSHN’s 
Scheduling Advisor to determine the best action to restore the system to the required level 
of QoS. 

The Control Module is responsible for accepting applications’ start and 
completion information from the CL. As an application executes, the CL sends the 
applications name and an event character- “S”, starting and “D”, done, periodically to the 


Control Module. With this information and a timestamp from the Control Module’s host, 
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it populates the PathDB. Once all time positions are filled in a particular path instance, 
the TPMS conducts timeliness calculations and the system determines if a QoS violation 
has occurred. The specification for each module is provided in Appendix B. 


Br MSHN Integration 


For the TPMS to work during execution of path-based applications, it must 
receive an application ID and an event character indicating that an instance of a 
datastream has arrıved at an application or that it has been passed to the next application. 
For this research, it was necessary to identify how communications are facilitated among 
the applications within the path. The testbed DynBench applications, which emulate an 
air defense system, establish sockets and send datastreams and messages using the 
read()andwrite() "C" programming functions. This is true whether applications are 
executed on a local or remote host. The read() and write() call interception of 
MSHN [SCHN98] were modified to send an event character and an applicationID to the 
TPMS Control Module. When an application receives a datastream though the read () 
function, the CL forwards to the TPMS the applicationID and the event character of “S”, 
which indicates the application is starting to process data. The TPMS then logs the time 
it received the message. When calculations are complete on each distinct datastream, the 
application forwards the datastream to the next application in the path using the write() 
function. At this point the CL again sends the applicationID to the TPMS, this time with 
an event character of "D" to represent the completion of data processing. This 
completion time is now logged by the TPMS. Application latency is determined by 


calculating the difference between start and completion times of an application. 
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Similarly, calculating the difference between the start time of the first application and the 
completion time of the last application in a path provides the path latency or TPT. 

The read() and write() functions are commonly used system calls; therefore, 
datastream receipt and forwarding must be distinguished from application-related usage. 
Applications that use end-to-end communication do so by establishing sockets and using 
the read() and write() functions. The client library has the ability to intercept 
system calls designed to create sockets and return their descriptors. The MSHN_sd_Class 
was developed to store and access these sockets' descriptors in a database. When a 
socket is created, its descriptor is inserted in the database. If a read () or write() call 
is intercepted, the file descriptor (fd) in the function call is compared against the 
MSHN. sd Class database. If a match is found, the system call is executing a datastream 
receipt or forwarding event and the CL will send notification to the TPMS Control 
Module. Use of other file descriptors is ignored. 

Since this implementation of the transparent QoS monitoring requires 
communications across multiple hosts, there must be some technique to access a common 
time reference. We have assumed that hosts within MSHN will not have perfectly 
synchronized clocks, so an implementation of the Network Time Protocol (NTP) was 
considered in past MSHN work. A remote process would query a timeserver and then 
use a formula to estimate clock offset and error [SCHN98]. In the current 
implementation, a User Datagram Protocol (UDP) server contained in the TPMS Control 
Module, accepts initiation and completion messages from the CL-wrapped applications 


communicating with UDP messages over the Internet Protocol(IP), and generates a 
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timestamp using the local clock time of the host. These messages along with the 
timestamps are recorded in the PathDB Module. 

This method of determining application start and stop time of a unique datastream 
remedies the errors generated by host clocks that are not synchronized. We have assumed 
that path-based applications initiate and complete in the correct order, but because we 
have network communications, reporting of those actions may arrive in an incorrect 
order. Ongoing work may include CL-to-CL communications implemented to assign 
path-instance identifiers to the datastreams as they pass from application to application. 

In future MSHN research, it is expected that the SpecDB Module will be 
incorporated into the RRD. Also the Evaluate and Alert Module’s functionality will be 
incorporated into the RSS and RRD, with both updating the SA. Since a discrete 
application can be represented as a path of one, continuous as well as discrete 


applications will be supported by the enhanced MSHN system. 


C. SUMMARY 


Desiderata and MSHN are both QoS-driven RMSs that require QoS monitoring to 
allocate resources in a best effort execution of an application. In a mission-critical 
system, the requested and required levels of QoS are synonymous. It is imperative that the 
RMS identify QoS violations, and react appropriately — for example, by migrating or 
distributing processes to other hosts, or by decreasing precision. Section A presented the 
Desiderata process for monitoring QoS and detecting QoS violations. Section B 


presented a proposed MSHN QoS violation detection method described as the 


4] 


Transparent Path Monitoring System (TPMS). Chapter V will detail experiments 
conducted and results obtained using MSHN's application wrapping technique with 


TPMS on Desiderata's DynBench air defense applications. 
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У. EXPERIMENTS AND RESULTS 


A good monitoring tool's resource usage does not hamper the execution of the 
application or the system that it is monitoring. This chapter investigates the overhead of 
the TPMS implementation. TPMS receives information from path-based applications 
wrapped with the MSHN CL. In past MSHN work, it was determined that the CL adds 
an average of 3% overhead to each system call [SCHN98]. Since timeliness is the key 
QoS metric in mission-critical systems, path latency will be the focus of this 
investigation. This experiment will use the DynBench applications that emulate an air 
defense system with path-based programs. Section A details the experimental design 
necessary to capture overhead data. Section B gives the results of the experiments 


conducted. 


A. EXPERIMENTAL DESIGN 


Our experiments focused on path latency measurements of DynBench applications 
when run (1) unmonitored and unwrapped, (2) monitored by Desiderata RMS and (3) 
wrapped and integrated with TPMS. The hypothesis is that TPMS will increase a path’s 
completion time, but the increase will be at an acceptable level and will not hamper 
DynBench’s execution. 


To better understand how DynBench applications work together see Figure 14. 
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Figure 14. DynBench Application Communications (DESI98] 


The scenario file gives initial input to the sensor simulating initial contact with aircraft 
and/or projectiles. The solid lines indicate transfer of a datastream or “track data” 
between applications. Applications shown as tiled in Figure 14 may be run as multiple 
instances to provide load sharing. Dashed lines indicate message traffic or a 
communication channel for simulated input. For example, the actuator program must 
send the positions of the missiles it has "fired" in response to threats to the sensor 
program. This updated track data 1s then passed throughout the system. 

The hardware used in this experiment was an ULTRA 10 Unix workstation with 


128MB RAM, and 300 MHz processor. The operating system is SUNG Solaris 5.5. Key 


to the path's completion time is the size of the data set used as input into the path. This is 


significant because the presence of threat aircraft results in missiles being fired and a two- 
fold increase in the input data to the sensor program. To maintain a baseline, the same 
scenario file will be used for each run. This file contains the start position and movement 
vectors for each aircraft. 


k Violation Detection 


The first experiment involves determining if the TPMS system can detect a QoS 
violation. Remembering that a QoS violation occurs when path latency exceeds the user 
defined deadline, it is necessary to determine what that deadline should be. The deadline 
for this experiment was determined statistically by calculating the standard deviation of a 
sample of Total Path Times (TPT) created with the TPMS. This resulted in the 


following data: (See Table 2.) 


—— 
(secs) 
Deadline 


Table 2. Deadline Derivation 







STD DEV 
(secs) 
0.021053 







To calculate the deadline value, the standard deviation was multiplied by 1.5 and added to 
the arithmetic average (mean). With this calculation technique, the deadline provided 
enough violations to demonstrate the effectiveness of the system. 


2. RMS Execution 


The second experiment entails comparing path latency through the DynBench 


applications in an unmonitored mode, with Desiderata QoS management, and wrapped 
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and reporting to the TPMS. The unmonitored DynBench will be used as a baseline for 
comparison of the other RMS' implementations. To maintain consistency, all parameters 
such as track data, hardware, and OS will remain the same. This is an important test 
because it should demonstrate if there 1s a significant overhead increase between an RMS 
using transparent QoS detection (MSHN-TPMS) and an RMS detecting QoS using 
function calls embedded within monitored applications (Desiderata). Additionally, it 
will be important to note how much overhead TMPS adds to the basic application suite. 

Prior to testing, modifications to the DynBench applications were necessary to effect 
timeliness monitoring. A sample experiment was conducted to confirm that cycle time 
padding delays were restricted to the sensor application (first application in the path). 
The next phase was to determine the best place to insert probes to measure time and 
negate the effect of padding. These modifications had no effect on how the system ran, 


and did not skew latency data. 


B. RESULTS OF EXPERIMENTS 
E: Violation Detection 


Execution of the first experiment was straightforward. The applications within 
the first DynBench path were wrapped and the path was given a deadline of 0.152678 
seconds to complete. А few points must be noted. Track data are initialized in the 
sensor process using a data file called the scenario file. From there track data are 
generated by the sensor process; therefore, there 1s no direct input to the sensor program 


that could be caught, in a read () call, which would be used to alert the TPMS. Because 
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of this, the TPMS registers the start of the filter manager application (FM) as the start of 
the path. 

By running 500 cycles of the path, it was found that 99.4% of the path completion 
umes met this arbitrary deadline. This demonstrates that the TPMS supplemented with 
the CL can transparently detect QoS latency violations. But at what price do we achieve 
success? This forms the basis for the second experiment. 


2 Effect of Monitoring on Path Latency 


DynBench's unmonitored run (no Desiderata or MSHN management) at 1000, 
2000 and 5000 cycles had total execution times of 20.426, 40.912 and 102.674 seconds. 
These times represented non-padded results and formed the baseline to which Desiderata 
and TPMS are compared. 

The initial hypothesis was that TPMS monitoring would increase the execution 
ume of the system due to its use of sockets to communicate to the CLs. This proved to be 
пие. TPMS increased execution time in the 1000 and 2000 cycle runs by a factor of 
0.007 seconds per cycle in comparison to the unmonitored DynBench run. It was 0.008 
when the cycle total was 5000. Desiderata increased execution time by 0.002 seconds per 


cycle for each of the three cycle periods. See Table 3. 
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Variations (secs/cycle) and CL (secs/cycle) 


INS 20.426 22.498 0.002 27.432 0.0070 
Completion Time 


(secs) 


2000 Cycles 40.912 44.810 0.002 55.347 0.0072 
Completion Time 
M 102.674 113.160 0.002 141.902 0.0078 
Completion Time 
(secs) 


Table 3. DynBench Execution Data 




















Table 3 demonstrates a uniform increase in execution time relative to cycle increase for 
all three versions of DynBench. Also, the execution time overages remained relatively 
consistent for each data set. 

It 1s clear that Desiderata has less of an effect on path completion time than does 
TPMS. For TPMS, the CL interception of system calls and passing initiation. and 
completion messages to the TPMS Control Module effects completion time of the 
applications within the path. The slight increase in seconds per cycle between 
unmonitored DynBench and TPMS upon cycle increase, indicates that there is some very 
small but cumulative delay introduced by TPMS as the test cycles increase. To further 
study this delay, we collected data on larger cycle runs of 10,000 for unmonitored 
DynBench and TPMS. Once again we had a slight increase in the seconds per cycle ratio. 
The most plausible reason for the increase is the multiple dynamic allocations and 
deallocations of memory for storing temporary data in the TPMS system. See chart in 


Figure 15 for comparison of overhead increases of Desiderata and TPMS. 
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SpuoooS 





1000 2000 5000 10000 
O Desiderata Number of Cycles 
OTPMS- CL 


EUnmonitored 


Figure 15. DynBench Overhead in Desiderata and TPMS 


As TPMS is further integrated into the MSHN architecture, further study will be 


required to determine if the increased overhead is an acceptable tradeoff for using COTS 


applications and transparent QoS monitoring. 
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VI. CONCLUSIONS AND FUTURE WORK 


This thesis accomplished the two primary objectives as outlined in Chapter I. 
First it describes, in detail, the QoS requirements for real-time, distributed applications 
based upon user criteria. Second, a technique was developed to transparently detect the 
QoS metric of timeliness within a path-based set of applications. This chapter discusses 


the contribution of this thesis and proposed follow-on work. 


A. CONCLUSION 


The Management System for Heterogeneous Networks (MSHN) requires usage 
information associated with applications that run within the MSHN system and status 
information for the resources within the MSHN scheduler's scope [SCHN98]. Тһе 
scheduler makes decisions based upon this information. MSHN's Client Library (CL? is 
wrapped around an application and transparently gathers resource usage and application 
data. This thesis presented a technique to identify ongoing timeliness QoS violations 
through extensions to the CL. 

The CL’s task is to intercept system calls and send information to the MSHN 
system. Chapter IV presented a method, utilizing this interception capability, to monitor 
the timeliness QoS metric of path-based (i.e. continuous) applications. This method was 
the Transparent Path Monitoring System (TPMS). TPMS calculated the end-to-end path 


latency and compared it against a predetermined deadline provided by the end-user. Ifa 
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QoS violation occurred, a flag was raised within the system. Within the context of a 
complete RMS, a responsive action to a QoS violation could be initiated. 

Though the TPMS could be added as an additional component to MSHN, it would 
be more appropriate to implement its functionality in MSHN's Scheduler, Resource 
Requirements Database (RRD) and Resource Status Server. Key to TPMS is its ability to 
monitor QoS without access to application source code. This lends itself to COTS or 
legacy software. 

Testing of TPMS with the DynBench air defense simulation applications, proved 
the hypothesis that TPMS would increase path completion times of the Dynbench system. 
The CL’s system call interception and reporting to the TPMS Control Module, increased 
the Total Path Time by an average of 0.007 seconds per path cycle. TPMS’ integration 
into the MSHN architecture will require further study to determine if the increased 
overhead is an acceptable tradeoff for using COTS or legacy software whose QoS is 


transparently monitored. 


B. FUTURE WORK 
1. Expansion of Existing MSHN Wrapper Functionality 


The development of the MSHN wrapper should proceed in two areas. In the 
current implementation, the MSHN CL is linked with the object code of the target 
application. The first area of research should be in development of a wrapping technique 
for executable code. The Executable Editing Library was developed at the University 


Wisconsin-Madison to accomplish similar goals [PORT99]. Also this topic 1s addressed 
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by Tim Fraser et. al. [FRAS99] in “Hardening COTS Software with Generic Software 
Wrappers.” The second area of research should be focused оп inter-wrapper 
communication. Currently each wrapped application communicates with the MSHN 
hierarchy but there may be some cases where applications need to “talk” to each other. 
Inter-CL communications provide the ability to tag data and trace its movement through 
MSHN’s architecture. 


2: Integration of Windows Application Monitoring 


The DoD is migrating to a Windows based environment in most situations. In 
fact the Department of the Navy has decided that all future automation purchases will be 
based on the Windows NT operating system [CINC97]. Because of this, techniques for 


monitoring resources on Win32/x86 machines will need to be developed. Microsoft® is 


working on a research project called Detours which is a library for instrumenting 
arbitrary Win32 functions on x86 machines. This system intercepts Win32 functions by 
re-writing target function images [HUNT99]. This work closely corresponds to the work 
MSHN accomplishes in a UNIX environment. Additional thought should be applied to 
methods of applying MSHN to this alternate platform while continuing to adapt it to 
updated versions of the UNIX and LINUX operating systems. 


3 Intergration of TPMS into MSHN 


In future MSHN research, it is expected that the SpecDB Module will be 
incorporated into the Resource Requirements Database (RRD). Also the Evaluate and 
Alert Module’s functionality will be incorporated into the Resource Status Server and 


RRD, with both updating and alerting the Scheduling Advisor. Since a discrete 
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application can be represented as a path of one, continuous as well as discrete 


applications will be supported by the enhanced MSHN system. 
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APPENDIX A. DATABASE DESIGN 


This appendix provides a detailed description of the databases created in the 
Transparent Path Monitoring System's modules. The initialization data file exists in text 
format and can be modified with any text editor. The remaining databases are created 


dynamically at runtime and are stored in memory to facilitate fast access. 


A. SPECIFICATION DATABASE 


To initialize the system, the user must create a data file that contains application 
names and, path Ids, lengths, and deadlines. When the initialization function in the 
SpecDB module parses the user created data file, it then creates and populates the 
specification database dynamically. The fields are given in Table 4. 


pathID Uniquely identifies a path. 


pathLength Defines the number of applications in a path. 


deadline The time in which the path must complete. 


next A pointer that points to the next specification 
node. 


appList A linked list that contains the Application 
Identification in the order that they occur in 
the path. 





Table 4. Specification Database 
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Figure 16 shows how the specification database logically exists in memory. 


Path 
Ран Deadline Next App 
Length зы" [р 


specDBPtr 


e E Multiple 
application IDs 


PathID En App 
a 
enn Deadline Next NINE ID 


specDBPtr 


е N Ds 
Figure 16. Specification Database in Memory 

B. PATH DATABASE 

Once populated, the specification database is static. In contrast the path database 
is constantly being updated with application timestamps, and the creation and deletion of 
path instances. Table 5 presents the fields of this database, and Table 6 details the fields 
of an instance node. An instance node maintains the application time information for a 
particular instance of a path. These instances are connected by means of a linked list and 
exist in memory only. The database is not stored between invocations of the TPMS. For 


graphical clarification, see Figure 13. 
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A linked list that contains multiple instances 
of the specified path. 


Table 5. Path Database 









Uniquely identifies a path instance. 
appCounter Defines the number of applications that have 
reported to this instance of the path 
next A pointer that points to the next path 
instance. 


An array of length pathLength that is built 


dynamically and holds application timestamp 
Table 6. Path Database Instance Definition 
















information. 
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APPENDIX B. TMPS MODULE SPECIFICATION 
This appendix details the specifications of each of the TPMS modules. This 
specification includes information on included libraries, and structure definitions. Also 


public and private class functions are defined. 


A. SPECDB MODULE 


e LIBRARIES INCLUDED 
<assert.h> - for the assert function 
<iostream.h> - for file input 
<stddef.h> - for NULL 
<time.h> -for time operations 


e TYPES DEFINED 
struct specDBrec - A cell/node in the list 


o DATA MEMBERS 


int pathID - path identification number 
int pathLength- the number of apps in the path 
float deadline - maximum path latency 


applicationID* applicationlDArray - An array that holds application 
names based on pathLength 


e PRIVATE METHODS DEFINED 
PtrTo - Returns a pointer to the element in current position 


e PUBLIC METHODS DEFINED 


specDBClass - Default constructor 

specDBClass - Copy constructor 

~specDBClass _ - Destructor 

ListIsEmpty - Test to see ıf no elements exist in list 
ListLength - Number of items in list 

ListInsert - Put an item into the list at position 
ListDelete - Remove an item at position from list 
ListRetrieve - Get an item at a specific position 


- - Assignment one class object to another 
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DisplayList - Displays the list created 


createSpecDB - Creates the specification database from an input file 
appPositionInPath-Returns input application’s position in its path 
getDeadline -Gets deadline value for input path 


B. PATHDB MODULE 


1. 


pathDB.h 
LIBRARIES INCLUDED 
<iostream.h> - for VO 
<assert.h> - for use with pointers 
"specDB.h" - to use specDBClass specDBrec 
“pathDBInstance.h" - to insert application times into path 
"evalalert" - to access goodInstance 


TYPES DEFINED 
Struct pathDBrec - A cell/node in the list 


o DATA MEMBERS 
int pathID - path identification number 
int pathLength - the number of apps in the path 
instanceClass instanceList - list of instances of path 


PRIVATE METHODS DEFINED 
PtrTo - Returns a pointer to the element in the current position 


PUBLIC METHODS DEFINED 


pathDBClass - Default constructor 

pathDBClass - Copy constructor 

-pathDBClass - Destructor 

ListIsEmpty - Test to see if no elements exist in list 
ListLength - Number of items in list 

ListInsert - Put an item into the list at position 
ListDelete - Remove an item at position from list 
ListRetrieve - Get an item at a specific position 
ListUpdate - Updates item at a specific position 

= - Assignment of one class object to another 
displayList - Displays the list created 

createPathDB - Creates the path database from SpecDB 
addAppTime - adds application time to path instance 
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ә 


pathDBInstance.h 


LIBRARIES INCLUDED 


<iostream.h> - for VO 

<assert.h> - for use with pointers 
«time.h» - for time operations 
"specDB.h" - for access to specDBClass 


TYPES DEFINED 
struct instance - A cell/node in the list 


o DATA MEMBERS 


int instID - The identifier for instance 
int appCounter — - Counts the number of reporting 
applications 


timeType timeArray[4] - An array that holds time information 


PRIVATE METHODS DEFINED 

PtrTo - Returns a pointer to the element in current position 
PUBLIC METHODS DEFINED 

instanceClass - Default constructor 

instanceClass - Copy constructor 

~instanceClass  - Destructor 

ListlsEmpty - Test to see if no elements exist in list 
ListLength - Number of items in list 

ListInsert - Put an item into the list at position 
ListDelete - Remove an item at position from list 
ListRetrieve - Get an item at a specific position 
ListUpdate - Updates item at a specific position 


= - Assignment of one class object to another 

displayInstanceList- Displays the list created 

instanceComplete - Determines if all time positions are filled 
in current instance 
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C. PATHTIMER MODULE 


e LIBRARIES INCLUDED 
#include “pathDBInstance.h” - to access instanceClass list 


e TYPES DEFINED 
None 


e PRIVATE METHODS DEFINED 
None 


e PUBLIC METHODS DEFINED 
calcTotalPathTime - Calculate total path time 
D. EVALUATE AND ALERT MODULE 


e LIBRARIES INCLUDED 
е #include “specDB.h” - to access specDBClass list 
e #include “pathDBInstance.h” — - to access instanceClass list 


e TYPES DEFINED 
None 


e PRIVATE METHODS DEFINED 
None 


e PUBLIC METHODS DEFINED 


goodInstance - Calculates to see if path made deadline 
evaluate - Checks to see if good instance 
raiseFlag - Raises a flag if path latency exceeds deadline 


E. CONTROL MODULE 


e LIBRARIES INCLUDED 


е "specDB.h" - to access specDBClass list 
e "pathDB.h" - to access pathDBClass list 
е <stdio.h> - for VO 

e <stddef.h> - to define NULL 

e <ermo.h> - for errors 

e <time.h> - to access time functions 
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<sys/types.h> - to access socket connections 


<sys/socket.h> - same 
<netinev/in.h> - same 
<netdb.h> - same 


TYPES DEFINED 
None 


PRIVATE METHODS DEFINED 
None 


PUBLIC METHODS DEFINED 
None 
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APPENDIX C. TPMS SOURCE CODE 


A. SPECDB MODULE 


А рота 


// FILE: specDB.cpp * 
77 * 
// AUTHOR: Kendal Polk as a modification of Template from Data С 
ДР Abstraction and Problem solving with C++ by Frank 5 
// Carrano, СН4,рр1 65. * 
/ / * 
// LAST MODIFIED: 6 June 2000 E 
/ / 

// PURPOSE: This is the source file for operations necessary for the* 
IR: specDB Module * 
ДИ * 
if © 


NK EE LEN ы аа ыда ыы ы к кык КККК К КК КАКА КЕКЕ КА e OK ORO ЕКЕЖ e Oeo m e o ook X ook КН 


include "specDB.h" 


include «fstream.h» 
imeludezestäderf h> 
#include <assert.h> 
#include <strings.h> 


struct specDBNode { 
specDBrec item; 
specDBNodePtrType next; 
Ir 


NEFFEN TITTEN I hehe ee he e TITTEN TEE IT TFT N © 


// SpecDBClass: Default constructor = 
EAN EHE ER UT TH TEN TR IT TUT N ET I IRRE ER EIERN 


SpecDBClass: :SpecDBClass (void): size(0), head(NULL) 
{ 
} 


f / * ko oec eoe ce he ehe he he e ee he ee e e e e e e e e ehe e e e e e ee KK KK e e e e ce ke cse ee e e Ж SK 


// SpecDBClass: Copy constructor 


d б 
// INPUT: const SpecDBClass& sourcelist - The source list to copy * 
// LOCAL: specDBNodePtrType newPrev - The new list head ^ 
/ / specDBNodePtrType origCur - local ptr Е 
ДА A 

* 


ках 


SpecDBClass::SpecDBClass(const SpecDBClass& sourcelist): 
size(sourcelist.size) 


{ 
specDBNodePtrType newPrev, origCur; 
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if ( sourcelist. head == NULL ) 
head = NULL; 
else { 
head = new specDBNode; 
assert (head != NULL); 
head->item = sourcelist.head->item; 


newPrev = head; 


for ( origCur = sourcelist.head->next; 
orig ur !-eNULDL; 
örigCur = Zerigctur--mexe а 
newPrev->next = new specDBNode; 
assert (newPrev->next != NULL); 
newPrev = newPrev->next; 
newPrev->item = origCur->item; 
} 
newPrev->next = NULL; 
} 
}// end 


(Жж оххх хк хк каке XK Е А Е 


// ~SpecDBClass: Destructor * 


JM EI D eux EXE ДД АЕ N ra 0 ZT 


SpecDBClass::-SpecDBClass(void) 


( 
int success; 
while ( IListIsEmpty() ) 
ListDelete(1, success); 
} 


МКК A X OE oo ES OO ex e ox ovo voc oo OO IS I aa 


// ListIsEmpty: Checks if the list is empty. pi 
ИХ * 
// RETURN: If list is empty the function returns TRUE, otherwise * 
ДА it returns FALSE. Г 
IH, * 
] / * ke e e e e e e e ee e hehe ee e hee ee eese eee e ese eec ee ke e ee e e ke e ce ke e e ck e ke e ke e ke ke k e kc x 
ante 
SpecDBClass: :ListIsEmpty (void) 
{ 

return(size == 0); 
} 
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P E E > АКИКАТ Fr Ха ххх ықы x o ouk c oec coo U k 


// ListLength: Returns the number of items in the list 5 
yy z 
// RETURN: Returns the number of nodes in the list. * 
ГА * 


Ах о to АССА Ех кк Сы АХЖ КЕ АЖЖ 


int 
SpecDBClass: :ListLength (void) 
( 


тесип елге); 


) 


С > + 


// PtrTo: Find the requested node in the list. 5 
ДИ * 
// INPUT: int position - specifies the position of the requested 5 
Ди поде. * 
/ / * 
// RETURN: If successful, returns a pointer to the requested node, * 
Ші otherwise it returns 0. * 
joy 5 

* 


[FERRERA RA ARE RARE RRA RARA he he e e he ee e esee eoe de de eoe de e e e e e ke e e e e ke kc ho e 


specDBNodePtrType 
SpecDBClass::PtrTo(int position) 
( 
specDBNodePtrType trav; 
тїр skip, 
if ( (positiom < 1) || (ровітіоп > ListLength()) ) 
return(NULL); 
else { 


trav - head; 


ton skip - 1; skip < position; skip++ ) 
trav = trav->next; 


return(trav); 
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IRRE TR TITTEN TE TE TEE TE TE TE N TE TE TA TE TEN AT TE TE TE TE TI TE TE ET N I A U FF FE 


1 
ДИ 
Ди 
Ди 
үү 
ДИ 
// 
// 
7 
A 


INPUT: 


LOCAL: 
OUBBUT: 


ListRetrieve: Gets data from specified node. А 
* 

int position - Position of node from which the data * 

is to be retrieved. * 

specDBNodePtrType cur - pointer to the desired item * 
specDBrec& dataItem - The parameter into which the* 

desired item is retrieved x 

int& success - Returns TRUE if the retrieve* 

was successful, FALSE ы 

otherwise * 


а о RD ECC атала атта ла E 


void 
SpecDBClass::ListRetrieve(int position, specDBrec& dataItem, 


( 


Пї ГЫ SUCCESS) 


specDBNodePtrType cur; 


success 


= ((posıtıon >= 1) && 
(position <= ListLength())); 


SOECES SA 


curn 


PtrTo (position); 


dataltem s cur-»item; 


) 


return; 


А дайла ылы лылы дылы TI IE лы лад я БК 


Ди 
2 
ДИ 
ү 7 
ДИ 
// 
ди 


ENP Ua. 


LOCAL: 


// ListInsert: Inserts new node into list. К 
* 

int newPosition - the position where to insert x 

зресОВгес  newItem - The item to insert 5 

ДЕ newLength - list length after insertion X 
SpecDBNocePtrType  newPtr - node to hold new value hi 
specDBNodePtrType prev - points to previous node for* 
reassigning pointers * 

int& success - TRUE if the insert was * 


И 
// 


OUTPUT: 


successful, otherwise FALSE * 


ДЖЕКА КАКА ER KT TE TEEN U I FE N U I I I 


void 
SpecDBClass::ListInsert (int newPosition, specDBrec newItem, 


( 


int 


int& success) 


newLength; 


specDBNodePtrType newPtr, prev; 


newLength = ListLength() + 1; 


success =((newPosition >= 1) сс 


(newPosition <= newLength) ); 


ir E 
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size - newLength; 
newPtr = new specDBNode; 
success =(newPtr != NULL); 
if ( success ) { 
newPtr->item = newltem; 
it í newest ion == 1) ( 
newPtr->next = head; 
head = newPtr; 
} else { 
prev = PtrTo(newPosition - 1); 
newPtr->next = prev->next; 
prev->next = newPtr; 
} 
} 
} 
return; 


O E ISA A 


// ListDelete: Delete node from the list. w 
// INPUT MEINE position - position of node to be deleted F 
// LOCAL: specDBNodePtrType cur - saved pointer (to head or * 
77 next) x 
I specDBNodePtrType prev - pointer to the previous cell* 
// OUTPUT: inte success - TRUE if the delete was * 
n successful FALSE otherwise* 


Ал = 


void 
SpecDBClass::ListDelete(int position, int& success) 


( 


SpecDBNodePtrType cur, prev; 


success - ((position »- 1) && 
(position «- ListLength())); 
if ( success ) ( 
size--; 
if ( pesteaene—— 1.) { 
cur = head; 
head - head-»next; 
) else ( 
prev = РЕ ТО (РОТЕ то =- I); 
eur = prev->next; 
prev->next = cur->next; 
) 


cur->next = NULL; 
delete cur; 
eur 


= NULL; 


69 


УКМК Е 


// SpecDBClass: assignment - * 
/ * 
// INPUT: const SpecDBClass& sourcelist - The source list to copy * 
// LOCAL: specDBNodePtrType newPrev - The new list head * 
m specDBNodePtrType origCur - local ptr * 
i : 

* 


ИТТЕ хх теке етек кат еее вое UE 


уола 
SpecDBClass::operator-(const SpecDBClass& sourcelist) 


( 


specDBNodePtrType newPrev, origCur; 
Size - sourcelist.size; 
if ( sourcelist.head == NULL ) 
head = NULL; 
else { 
head = new specDBNode; 
assert (head != NULL); 
head->item = sourcelist.head->item; 


newPrev = head; 


for ( origCur = sourcelist.head->next; 
Orig ur Г; 
erigenr 9origCuEe--nexrt ( 
newPrev-»next - new specDBNode; 
assert(newPrev-»next != NULL); 
newPrev = newPrev->next; 


newPrev->item = origCur->item; 


} 


newPrev->next = NULL; 


} 


Ду ЖЖ ХЕХЕ КК КЕ TE TE TE I TR FE U ET EN FE EEE A A eoe Xo 


// displayList: Displays the list created А 
У ШОСАШ ТЕПЕ position - the position where to display node + 
ДИ ine success - true when node retrieved * 
5 specDBrec DBrec - the item to display * 


NN EFFEKTE TEN IE TE ET TE KIT EN TE U TUT RT TU N I TU N I U U EL ET U КАКА ЖЕКА КЕКЕК 


void SpecDBClass::displayList() 
( d 
specDBrec DBree; 
їп рост топ к ат: 
int success; 


while(position <= ListLength() ) 
{ 


ListRetrieve(position, DBrec, success); 
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cout<<"\n Pate DBrec.pathID; 
Gouee<" Length ” << DBrec.pathLength; 


cout<<" sec=> "<<DBrec.deadline.tv_sec<<", usec => "; 
cout««DBrec.deadline.tv usec««endl; 


for (int appPos= O;appPos < DBrec.pathLength; ++appPos) 
{ 


cout<<" App - "<<DBrec.applicationIDArraylappPos]; 
} 
position++; 
)//while 
cout<<endl; 
}//end 


ER аке жс а o ox 


// createSpecDB: Builds the spec DB from input file * 
// INPUT: char* inputfile - the name of the file used to * 
// build database x 
// LOCAL: specDBrec DBrec - Item to insert into the list * 
/ / applicationID tempName[25] - Used to hold name of app * 
/ / int success - true if node inserted in list » 

* 
К NNI eL as s Ree 


void SpecDBClass::createSpecDB(char *inputfile) 
( 


specDBrec DBrec; 
char tempName[25]; 
int success; 
//open an input data file containing information on how the paths 
// are constructed 
// and deadline information 
ifstream specDBInputFile(inputfile,ios::in); 
//populate the Database 
while(specDBInputFile »» DBrec.pathID) 
( 
specDBInputFile »» DBrec.pathLength; 
specDBInputFile »» DBrec.deadline.tv sec; 


SpecDBInputFile»» DBrec.deadline.tv usec; 


DBrec.applicationIDArray = new 
applicationID[DBrec.pathLength]; 


//populate the array with application IDs 


for (int count=0; count< DBrec.pathlength; count++) 


( 
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specDBInputFile >>tempName; 
DBrec.applicationIDArray[count] = strdup(tempName) ; 


ListInsert (ListLength()+1,DBrec,success) ; 


}//while 
specDBInputFile.close(); 


)//end 


Ао оо а 


// find PathID: Finds Path Identification number based on * 
"n application ID m 
// INPUT: int application - the number of the application * 
// LOCAL: specDBrec DBrec - Item to search for a applicationID * 
dt int appNum - Used to hold positions x 
ДИ int specDBposition - Used to hold positions = 
ДИ int success - true if node inserted in list = 
А Еочпа - true if application found in path * 
// RETURN: the pathID of the input application Я 

* 


ГИЛ ооа дд Ж 


int SpecDBClass::findPathID(applicationID application) 
( 


сресОВгес DBrec; 

jm appNum; 

ine specDBposition = 1; 
int success; 

Int Tounece wis 


//Get a Path record and go the list of applications 
//to see if it is the correct one. 


while ((specDBposition <= ListLength()) && (found !=0)) 
{ 


ListRetrieve(specDBposition, DBrec, success); 
im appArrayPos = 0; 


while ((found!z0) && (appArrayPos « DBrec.pathLength) ) 
( 


found =strcmp 

(DBrec.applicationIDArraylappArrayPos] ,application); 
appArrayPos++; 

)//while 


specDBposition++;//continue through all paths if necessary 


2 


)//while 


return DBrec.pathID; 


Df OPE AS ККЕ КОК КАКА А КАК КЕКЕК А а пол пл то оро ар Ke ok ok e eoo oo e e e x 


// appPositionInPath: Finds application position in path * 


the number of the application 2 
position іп specDB * 
Item to search for applicationID* 
Used to hold positions 

true if node inserted in list 
true if reportingApplication is 


)//end 

// INPUT: int reportingApplication - 

Ди specDBposition - 

// LOCAL: specDBrec DBrec - 

/ / int appArrayPos - 

Ly int success - 

И found - 

/ / 

// RETURN: the path location of the input application 


* 
* 
* 
found in a path > 
* 
* 


ааа а атака E NOR Wo oo 


int SpecDBClass::appPositionInPath(applicationID reportingApplication, 
int specDBposition) 


( 


specDBrec DBrec; 

int success; 

ine found = 1; 

InG appArrayPos = 0; 


//go to correct path based on specDBposition 


ListRetrieve(specDBposition, DBrec, success); 


//find application position in that path 


//strcmp function returns a zero if strings match 


while ((found != 0) && (appArrayPos « DBrec.pathLength) ) 


( 


found = strcmp(DBrec.applicationIDArraylappArrayPos], 
reportingApplication); 


//since Array enumeration is 1 less than logical position - 


increase 


//appArrayPos even if found == true 


аррАггауРоз+ +; 


// if entire array searched with no result then return a -1 


73 


return (found=- 07 Tappärraybos: 21 


}//end 


д 


// getDeadline: Based on path ID returns deadline information 


ДА ТЫРЫТ. ne patie ip - the number of the path 

// LOCAL: specDBrec DBrec - Item to search for applicationID 
/ / int success - true if node inserted in list 

/ / found in a path 


// RETURN: the path deadline information 


ТЕХ кк кк км жж же жем как а тк кк кк жек кк СИЕ 


timeType SpecDBClass::getDeadline(int pathID) 


; SpecDBrec tempDBrec; 
int success; 
ListRetrieve(pathID,tempDBrec,success); 
return(tempDBrec.deadline); 

}//end 


B. PATHDB MODULE 


1. PathDB Source Code 


gk NON Ko EE EU UK E E U I I ERWIN EEE TU U I A I I N АЕК 


// FILE: pathDB.cpp z 
2 я 
// AUTHOR: Kendal Polk as a modification of Template from Data * 
n Abstraction and Problem solving with C++ by Frank s 
ДИ Carrano, CH4,pp165. * 
ДИ % 
// LAST MODIFIED: 6 June 2000 © 
/ х 
// PURPOSE: This is the source file for operations necessary for the* 
/ / pathDB Module 5 
V7 i 
a) * 


у u a I 


#include <iostream.h> 
#include <fstreéam.h> 
#mMiclude <stddef h> 
#include <assert.h> 
#include "pathDB.h" 
#include "pathTimer.h" 
#include "pathDBInstance.h" 


struct pathDBNode { 


pathRec item; 
pathDBNodePtrType next; 
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ү; 


И ох ох АДАК Ххх ххх 


// pathDBClass: Default constructor - 


cux LC UE ee ee KO OO COR TE кк к 


pathDBClass::pathDBClass(void): size(0), head(NULL) 


( 
) 


Урук A ааа айы ты ыды аа ады 


// pathDBClass: Copy constructor 


/ / * 
// INPUT: const pathDBClass& sourcelist - The source list to copy * 
// LOCAL: ptrType newPrev - The new list head * 
ДИ ptrType origCur - local ptr * 
у * 

* 


Mc атта атта KE а UO ENIRO UA 


pathDBClass::pathDBClass(const pathDBClass& sourcelist): 
size(sourcelist.size) 


( 
pathDBNodePtrType newPrev, origCur; 


ıf ( sourcelist.head == NULL ) 
head = NULL; 
else { 
head = new pathDBNode; 
assert(head != NULL); 
head->item = sourcelist.head->item; 


newPrev = head; 


for ( origCur = sourcelist.head->next; 
origeur - NULL; 

Orig Ur = ~Origcur-snext ) ( 
newPrev->next = new pathDBNode; 
assert (newPrev->next != NULL); 
newPrev = newPrev->next; 
newPrev->item = origCur->item; 


} 


newPrev->next = NULL; 


} 
y// “ena 


JETA ASS RAR RIC RACE NARA ARRE RR AR ARA ARA RARA ARA RARA RARAS 


// -pathDBClass: Destructor * 


ух кк ххх AAA he oe hee ee e hee he e che hee oe e he he he ee he e ee ARA 


pathDBClass::-pathDBClass(void) 
( 


int success: 
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while ( !ListIsEmpty() ) 
ListDelete(1, success); 


f f * Koo ecce oe che ke cec cse oe hee eoe eee ehe TEE Хх») +» КК Ж e ce ХХ + e A a a v ke 


// ListIsEmpty: Checks if the list is empty. z 
Ди x 
// RETURN: If list is empty the function returns TRUE, otherwise ы 
ДИ it returns FALSE. * 
/ / x 

* 


/ҒХХХХХХХ ХХХ e eee oe oe e e eoe eese oe e eee eee e eoe eee e e coe ee e eoe ee eoe oe ecce e eee ee ee 


Int 
pathDBClass: :ListIsEmpty (void) 
{ 
return (size == 0); 
} 


[LL BRRRREREKRERKREREKKERKEKKEKEEKEEKEKKERERKERKEKERKEKKEKAEKKEKEKKEEKKEKKKKEKKKKEKK EX 


// ListLength: Returns the number of items in the list Е 
Да $ 
// RETURN: Returns the number of nodes in the list. * 
V7 ii 


[FERRERA RARA RARE ARA hee oe echec ec eoe oec ec ecce e e e e eee eee se oe TI e n e x 


TAE 
pathDBClass::ListLength (void) 
{ 

return (size); 


} 


f f ****cko heo hohe ee e hehe ode he che oe eoe che he he e e ЖЖС ХА ЖА echec N IE КК ХАККА АККА Хх Хх Жк ххх 


// PtrTo: Find the requested node in the list. * 
y. С 
// INPUT: int position - pathifies the position of the requested * 
/ / node. * 
ДА $ 
// RETURN: If successful, returns a pointer to the requested node, * 
7b otherwise it returns 0. * 

* 

* 


И а 


pathDBNodePtrType 
pathDBClass::PtrTo(int position) 
{ 


pathDBNodePtrType trav; 
int Skip; 
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if ( (position « 1) || (position > ListLength()) ) 
return(NULL); 
else ( 
trav - head; 


for ( sheep - 1; skip < position; зКър++ ) 
trav = trav->next; 


return (trav); 


A e a e A ke kc CK UI de e e e e 


// ListRetrieve: Gets data from specified node. x 
74 7 
// INGUT Sint position - Position of node from which the x 
77 data is to be retrieved. * 
// | z 
// LOCAL: pathDBNodePtrType cur - pointer to the desıred item * 
// OUTPUT: pathDBrec& dataltem - The parameter into which the Е 
И desired item is retrieved = 
ИА int& success - Returns TRUE if the retrieve Е 
А was successful, FALSE * 
27 otherwise Е 

* 


UD E те ктк к ктк кк KEN U eo oc XXX 


void 
pathDBClass::ListRetrieve(int position, pathRec& dataltem, 
int& success) 


( 
pathDBNodePtrType cur; 


success - ((position »- 1) && 
(position <= ListLength())); 


if ( success ) { 
cuts e PtrTolposutuioB); 
dataItem = cur->item; 

} 

return; 


p 


[FERRERA RARA RARA RRA AAA AA RARA ARA AAA RAR 


ListUpdate: Updates data from specified node. 


INPUT mT int position - Position of node from which the 


data is to be updated. 
Reference to data-item to 


which the data from the node is to be 


copied. 


pathDBrec& dataltem - The parameter into which the 
desired item is retrieved/updated. 


LOCAL:  pathDBNodePtrType cur - pointer to the desired item 


OUTPUT: int& success - Returns TRUE if the update was successful 


FALSE otherwise 


ГІ ХХ ХАКАС КК ХХХ ЖА ЖЖ ЖАТА А ААА АХЖ ЖАСА Қ Ж GRO EORR RU Gee ORO OC OUR RUE 


void 
pathDBClass::ListUpdate(int position, pathRec& dataltem, 


( 


) 


int& success) 
pathDBNodePtrType cur; 


success - ((position »- 1) && 


(position <= ListLength())); 


ir ( success ) ( 
eur =SPtrrio (posıtıon); 
cur->item = dataltem; 


} 


return; 


А Ал I UI 


ЖА 


TL RR RRR RRR RRR RRR AR RK ON CN EUR COR c OO қал атакка атак EO ER а а ан 


ListlInsert: Inserts new node into 1156. 


INPUT: int newPosition - the position where to insert 
the new node 
pathDBrec newltem - The item to insert 
LOCAL: int newLength - list length after insertion 
pathDBNocePtrType newPtr - node to hold new value 
pathDBNodePtrType prev - points to previous node for 
reassigning pointers 
OUTPUT: int& success - TRUE if the insert was successful, 
otherwise FALSE 


void 


pathDBClass::ListInsert(int newPosition, 


( 


int& success) 


INE newLength; 
pathDBNodePtrType newPtr, prev; 
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pathRec newltenm, 


* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 


ЖООБ Б ЖО ЕЕ Жж Хо хх Жж о т ВЯ ж 


newLength = ListLength() + 1; 


success =((newPosition >= 1) && 
(newPosition <= newLength)); 
if ( success ) ( 


size - newLength; 
newPtr = new pathDBNode; 
success =(newPtr != NULL); 
ie К (ШМёпссеге ){ 


newPtr->item = newltem; 


if ( newPosition == 1) ( 
newPtr->next = head; 
head = newPtr; 
} else { 
prev = PtrTo(newPosition - 1); 
newPtr->next = prev->next; 
prev->next = newPtr; 
} 
} 
} 
return; 


} 


> м: ee УЖ Ж кх КОХ хк 


// ListDelete: Delete node from the list. X 
ДИ * 
// INPUT: int position - position of node to be deleted. Б 
// LOCAL: pathDBNodePtrType cur - saved pointer (to head or next) * 
ШҰ pathDBNodePtrType  prev- pointer to the previous cell Ж 
jf OUTPUT. Sates success - TRUE if the delete was successful, и 
/ / FALSE otherwise. * 
ny % 
ИЕ ОИСИ c CK ON EGER cO ROC DPA E Kee ee e x 


void 
pathDBClass::ListDelete(int position, int& success) 
( 

pathDBNodePtrType cur, prev; 


success - ((position »- 1) «« 
(position <= ListLength())); 


if ( success ) { 

size--; 

ТЕ (ресвшвиоп -- 1) ( 
cur = head; 
head = head->next; 

} else { 
prev = PtrTo(position - 1); 
eur = prev->next; 
prev->next = cur->next; 
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cur-»next - NULL; 
delete cur; 
СНЕ = ЗЕ. 


} 


ДУХА КК ЕКА 


// pathDBClass: assignment - * 
/ * 
// INPUT: const pathDBClass& sourcelist - The source list to copy * 
// LOCAL: pathDBNodePtrType newPrev - The new list head E 
/ / pathDBNodePtrType origCur - local ptr * 
pl * 
* 


f f| * eoe coe che che he che che e de hee e e he che cede e see de he e AAA AAA AAA RARA AAA RRA AAA 


уола 
pathDBClass::operator-(const pathDBClass& sourcelist) 
( 


pathDBNodePtrType newPrev, origCur; 
size - sourcelist.size; 
if ( sourcelist.head == NULL ) 
head = NULL; 
else { 
head = new pathDBNode; 
assert (head != NULL); 
head->item = sourcelist.head->item; 


newPrev = head; 


for ( origCur =  sourcelist.head-»next; 
eragcur != NULL; 
от таспи Sori gCur->next Ti 
newPrev->next = new pathDBNode; 
assert (newPrev->next != NULL); 
newPrev = newPrev->next; 


newPrev->item = origCur->item; 


} 


newPrev->next = NULL; 


JEUNE EORR A e A ала ее 


// displayList: Displays the list created xu 
ИД GOCAL-. 1n€t position - the position where to dispay node * 
Ж. success - true when node retrieved form list* 
Ди pathDBrec DBrec — the item to display = 


ИГЕ к как хз ааа жала А жж а ж Е 


void pathDBClass::displayPathList() 


( 
pathRec pathDBrec; 
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ine position = 1; 
int success; 


while(position «- ListLength()) 

i ListRetrieve(position, pathDBrec, success); 
cout<<"\n Path " << pathDBrec.pathID; 
cout««" Length " «« pathDBrec.pathLength; 
pathDBrec.instanceList.displayInstanceList(); 
position++; 


)//while 
)//end 


Кккк хк кх кх ккк хык КККК Хх ххх ххх kK kk e eec esee ce ke e e dece cce e e e € € 


// cxeatePathDB: Builds the spec DB from input file * 
// INPUT: char* inputfile - the name of the file used to = 
// build the database = 
// LOCAL: pathrec tempPath - Item to insert into the list * 
А specDBRec DBrec - Used to hold temporary information К 
/ / int success - true if node inserted in list x 
/ / position - retrieval point 


JJ EEUU MX ккк кк А ккк К EE ак кк ККЕ ЖЖЖ АЖ 


void pathDBClass::createPathDB(SpecDBClass inputList) 
( 


pathRec tempPath; 
SpecDBrec DBrec; 

Де success; 

int position = i; 


while (position <= inputList.ListLength()) 

{ 
inputList.ListRetrieve(position, DBrec, success); 
tempPath.pathID = DBrec.pathID; 


tempPath.pathLength = DBrec.pathLength; 
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* 


position++; 
ListInsert (ListLength() +1,tempPath, success); 
}//while 


}//end 


P/[FEERERAERERE AAA RARA RAR AR RARA RARA RARA RA RARE RAR AA RARA AAA ARA RARA AAA 


// addAppTime: Inserts new time in instance list. т 
// INPUT: char appStatus - signals start or stop of an application * 
/ / applicationID reportingApplication - reporting app number* 
ИЛ timeval CurrentTimePtr- pointer to current time value* 
ИД SpecDBList inputList - accessed to determine * 
/ / deadline = 
И ОСА: ЛЕ PathID - ID of path = 
77 instancelnsertionPoint- shows where to place in * 
/ / list Е 
IH pathPosition - identifies app position in path* 
27 currentPosition- counter for moving through list* 
ДИ timeArrayLength- length of array of times - 
Ди totallnstances - used to compare against counter* 
n timeArrayInsert- position to insert in timearray* 
ДИ success - used as a boolean x 
/ / instanceDone - used as a boolean * 
ДИ timelnserted - used as a boolean * 
Ду j 
ДИ pathDBrec tempPathRec - temporary path DB record x 
ДИ Е 
ДИ зресОВгес ГепрОВгес - temporary spec DB record * 
// z 
ША timeType  TPT - total path time * 
ү deadline - deadline for the path x 
"s я 
m instance firstInstance - used to create an instance * 
E currentinstance- used to manipulate an instance * 
ДИ A 
i pathDBNodePtrType updatePathPtr- walks down path x 
Ди list * 

ж 


До ааа ааа а 


void pathDBClass::addAppTime(char appStatus, 
applicationID reportingApplication, 
timeval* currentTimePtr, SpecDBClass inputList) 


int PathID, instanceInsertionPoint, pathPosition; 
ante eurrentPosition s 1; 

ine timeArrayLength, totalliInstances,timeArrayInsert; 
int success, instanceDone; 

ine timeInserted = 0; 
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pathRec tempPathRec; 


specDBrec tempDBrec; 
timeType TPT,deadline; 
instance firstInstance,currentInstance; 


pathDBNodePtrType updatePathPtr; 


//find the Path the application belongs to 
PathID = inputList.findPathID(reportingApplication); 


liget correct" path 
updatePathPtr - PtrTo(PathID); 


//determine how many applications in the Path 
timeArrayLength= updatePathPtr->item.pathLength - 1; 
//find the position of the application in the path 


pathPosition = inputList.appPositionInPath 
(reportingApplication, PathID); 


#ifdef TPMS_DEBUG 
cout<<"pathPosition = "<<pathPosition<<"\n"; 
#endif ` 

//is this the first application of the path? 


if((pathPosition == 1)&&(appStatus -- 'D')) 
( 


//if this is the first application of the path AND it is 
// reporting that it is starting then 
//create an instance and put this time in it. 
// create an instance 
cout<<"creating new Instance\n"; 
instanceInsertionPoint = updatePathPtr-> 
item.instanceList.ListLength() +1; 

success= (firstInstance.timeArray != NULL); 

#ifdef TPMS_DEBUG 

ıf (success) cout<<"success with time"<<endl; 


#endif 


//correct for a negative fraction of second 
if(currentTimePtr-»tv usec « O)( 
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if (currentTimePtr-Stv see == 0) { 
currentTimePtr->tv_sec -= 1; 
currentTimePtr->tv_usec += 1000000; 
} 
else{ 
currentTimePtr->tv_usec *- -1; 
)//end if-else 
} 
else if(currentTimePtr-»-tv sec < 0) { 
currentTimePtr--tv sec += 1; 
currentTimePtr->tv_usec = 1000000 - 
currentTimePtr->tv_usec; 
)//end if 


firstInstance.timeArray[0]= *currentTimePtr; 


firstInstance.appCounter = 1; 


updatePathPtr->item.instanceList.ListInsert 
(instancelnsertionPoint £irstinstance, success)” 


)//end тт 


else if (pathPosition /- 1) 
//this is not the first application and we must find the location 
// for this application time IF it is a application complete time 


( 


totallnstances = updatePathPtr-> 
item.instanceList.ListLength(); 


#ifdef TPMS DEBUG 
cout<<totallnstances<<" = Totallnst "<<"\n"; 
#endif 
while((currentPosition <= totalInstances) && !timelnserted) 
{ 


//get the list of instances from the correct path 

updatePathPtr->item.instanceList.ListRetrieve 
(currentPosition,currentInstance,success); 

//determine if the app time goes to this instance 


if ((pathPosition - currentInstance.appCounter)--1) 


( 
//place this application time in the correct 


//time position 


timeArrayInsert = currentInstance.appCounter; 
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currentInstance.timeArray[ timeArrayInsert ]- 
*"cubkrentTTmerPcr; 


currentinstance.appCounter++; 

timelnserted = 1; 

//Update new list information 

updatePathPtr->item.instanceList.ListUpdate 
(eurrentPösition, currentlInstance, success); 

instanceDone = updatePathPtr-> 


item.instanceList.instanceComplete 
(updatePathPtr->item.pathLength,currentInstance) ; 


if (instanceDone) 


( 

TPT = calcTotalPatht me reurrentiInstance) ; 
#ifdef TPMS_DEBUG 

cout<<" I am here in instanceDoneWMn"; 
#endif 

deadline = inputList.getDeadline (PathID); 


evaluate (deadline, TPT); 


updatePathPtr->item.instancelist. 
ListDelete (1, success); 


ДЕГЕ 
)//end if 
if (!timelInserted) 


currentPosition++; 
//continue to next position in list 


7f location for time'noctwrocund here 


)//while 


}//if-else 


)//end 
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ри PathDBInstance Source Code 


ДК Ааа тат ааа аа так а DE 


// FILE: pathDBInstance.cpp * 
ү * 
// AUTHOR: Kendal Polk as a modification of Template from Data * 
ДИ Abstraction and Problem solving with C++ by Frank = 
Ди Саспаше, (БА I5 А 
/ / = 
// LAST MODIFIED: 6 June 2000 * 
2 = 
// PURPOSE: This is the source file for operations necessary for the* 
7 pathDBInstance Module z 
ДИ = 
Ди = 
МТК ТК КЕТ Кк ат атта ааа ааа тата аа 


#include "specDB.h" 
+include <stddef.h> 
#include <assert.h> 
#include "pathDBInstance.h" 


struct instanceNode { 
instance iten; 
instanceNodePtrType next; 

I5 


ЖТК КК КАК а E кта а атта 


// pathDBClass: Default constructor * 


> 5 


instanceClass::instanceClass(void): size(0), head(NULL) 
( 
) 


Ду ЖЖ ХХХ КА ААА КАКАЯ ККЖ жс а Е 


// pathDBClass: Copy constructor * 
ДИ * 
// INPUT: const pathDBClass& sourcelist - The source list to copy * 
// LOCAL: ptrType newPrev - The new list head * 
Ж. ptrType origCur - local ptr = 
А * 

* 


ДАЖЕ ЛАКА АК К 


instanceClass::instanceClass(const зпсЕапсес1 ао зошксей с - 
size(sourcelist.size) 


1 
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instanceNodePtrType newPrev, origCur; 


if ( sourcelist.head == NULL ) 
head = NULL; 
else { 
head = new instanceNode; 
assert (head != NULL); 
head->item = sourcelist.head->item; 


newPrev = head; 


for ( origCur = sourcelist.head->next; 
origéur != NULL; 
origCur = origCur->next ) { 
newPrev->next = new instanceNode; 
assert (newPrev->next != NULL); 
newPrev = newPrev->next; 


newPrev->item = origCur->iten; 


newPrev->next = NULL; 


} 
}// end 


NR REIT I N I I U I TI EN TU N HE TR TE FT ER TE A U U I N I UF A I U хаж 


// ~pathDBClass: Destructor * 


Jof RRR км а А E RR ARE SR ЖЖЖ кке кк жж 


instanceClass: :-instanceClass (void) 


{ 


nE SUCCESS: 


while ( !ListIsEmpty() ) 
ListDelete(1, success); 


DICERE хикки ИСО аа кла хаж u 


// ListIsEmpty: Checks if the list is empty. * 
zy 5 
// RETURN: If list is empty the function returns TRUE, otherwise * 
// it returns FALSE. = 
£T * 

* 


]//***h* *uk k k kk e kokkok kok ok ck ee ook ke ek ok ck ook eoe eoe eek ee eoe ee e e ee hehe hee e ee e e e ok e хк 


amt 
instanceClass: :ListIsEmpty (void) 
{ 
return(size == 0); 
} 
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NIEREN TEEN TE TE TE TE TE KT TE TH TE TE I KT TH TE TI N I A KH TH N U a ak 


// ListLength: Returns the number of items in the list = 
// + 
// RETURN: Returns the number of nodes in the list. * 
ИХ x 


о А 


dye 
instanceClass::ListLength(void) 


( 


returni ге) 


} 


[[AFEFFRFEFRAERRAEARERNRERERER ERA RARA ERA RRR RR AURA ERE RARE RARA RARA RARA 


// PtrTo: Find the requested node in the list. 5 
ДА * 
// INPUT: int position - identifies the position of the requested * 
ДА поде. * 
Ди х 
// RETURN: If successful, returns a pointer to the requested node, * 
Ди otherwise it returns 0. E 
ДИ б 

ж 


К хх ккк кк АКК Ккк ххх кх АККж ЖЕ ох хх ккк КА кк Кж ККК кх Ж 


instanceNodePtrType 
instanceClass::PtrTo(int position) 
( 
instanceNodePtrType trav; 
Inte Skip, 
if (position < 1) I] (position = ListLength(I) ) 
return (NULL); 
else { 
trav = head; 
ftor skıp = l; skip < Розе: КЕ) 
trav - trav-»next; 


return(trav); 


f ***** TE TER e he hee e ke ehh e hehe ke eee e he ke See ee hee e TI TI ET I TI I EN O* 


// ListRetrieve: Gets data from specified node. я 
74 * 
LI INPUT apine position - Position of node from which the * 
| data is to be retrieved. * 
ДИ * 
// LOCAL: ptrType cur - pointer to the desired item * 
// OUTPUT: instance& dataltem - The parameter into which the * 
FL desired item is retrieved = 
7. аа & success - Returns TRUE if the retrieve m 
/ was successful, FALSE * 
Да otherwise Li 

* 


NER ХХХ ЖЕЖ ЕКЕ АХА КЭС ЖЖ ЖЖЖ ЖОСА СА жак se sic cO e oec e seco we ce e E U 
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void 
instanceClass::ListRetrieve(int position, instance& dataltem, 
int& success) 


( 


instanceNodePtrType cur; 


success = ((position >= 1) && 
(DosityongswbostLength())); 


if ( success ) ( 
eur < РегТо(розшЕтоп); 
dataltem = cur->item; 

} 

тесиги: 


f f Ee ккк ккк кх хх ххх ххх ж хк кх кх ххх хх ххх ххх хх ххх кж ххх ke ke КК ККК Ж NN 


// ListUpdates: Updates data from specified node. 
/ / * 
// INPUT: int position - Position of node from which the * 
/ / data is to be retrieved. * 
ДИ instance dataltem - The parameter into which the В 
/ / desired item is retrieved f 
m * 
// LOCAL:  instanceNodePtrType cur- pointer to the desired item * 
L/ OUTPUT: int & success - Returns TRUE if the retrieve * 
y was successful, FALSE * 
7/ otherwise * 

* 


f | Ne eoe ee he e hehe he de de eoe ee eode ede che eee e de heces e che ehe he eoe e dee hee ee e e ee Ж кх хх хх Ж хх ж 


void 
instanceClass::ListUpdate(int position, instance dataItem, 
int& success) 


( 


instanceNodePtrType cur; 


success = ((position >= 1) && 
(position <= ListLength())); 


if ( success ) { 
сиг -тРенто( роза спопум: 
cur->item = datalten; 


песоси 
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К кк кх кк ккк ккк кх кх хк хк КККК КККК ККК СЕНС 


// ListInsert: Inserts new node into list. * 
Ди * 
22 INPUT: ine newPosition - the position where to insert * 
Ai the new node * 
Ди instance newItem - The item to insert * 
ДИ 5 
LOCAL: АВЕ newLength - list length after insertion 3 
2/ instanceNodePtrType newPtr- node to hold new value * 
27 prev - points to previous node for * 
// reassigning pointers Е 
oy * 
// OUTPUT: int& success - ТВОЕ if the insert was = 
// successful, otherwise FALSE E 
ДИ $ 
[FERRERA ARA RARA ARA RARA ARA RARA AA RARA AAA ARA RARA RARA AAA ARA К Ж € 


мота 
instanceClass::ListInsert(int newPosition, instance newItem, 
Iint& suecess) 
{ 
Int newLength; 
instanceNodePtrType newPtr, prev; 


newLength = ListLength() + 1; 


success =i@inewPosition >= 1) && 
(newPosition <= newLength) ); 


if ( success ) | 
size - newLength; 


newPtr = new instanceNode; 
success =(newPtr != NULL); 
Esc successo) | 


newPtr->item = newltem; 


if ( newPosition == 1) | 
newPtr-»next - head; 
head = newPtr; 
} else { 
prev = PtrTo(newPosition - 1); 
newPtr->next = prev->next; 
prev->next = newPtr; 
} 
} 
} 
return; 
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ах 


// 
// 


ока 


ListDelete: Delete node from the list. 


INPUT: int position - position of node to be deleted. 

LOCAL: instancNodePtrType cur - saved pointer (to head or next) 
prev- pointer to the previous cell 

OUTPUT: int& success - TRUE if the delete was successful, 


FALSE otherwise. 


void 
instanceClass::ListDelete (int position, int& success) 


{ 


Плата ктк т кек кке кта KE ok eco ee oleo e eoe Sek 


instanceNodePtrType cur, prev; 


success = ((position >= 1) && 


(position <= ListLength())); 


if ( success } { 

size--; 

ic position .=— 1): { 
cur = head; 
head = head-»next; 

} else { 
prev = ВЕТ То (ро-зтЕтом - 1); 
Cur = prev->next; 
prev- nex SS next, 


) 


cur->next = NULL; 
delete cur; 
CHE = NULL; 


// instanceClass: assignment = 


7 

// INBUT: const instanceClass& sourcelist - The source list to copy 
// LOCAL: instanceNodePtrType newPrev - The new list head 

ИУ instanceNodePtrType origCur = Шева! рег 

// 


+ + + + + + + + 


f| /[ FC e ke ee eee ehe e e ee e ke e e N eee e ee e e e ee e e ee hee eee eee eee eee ee ee eee e e k ke k ke 


void 


instanceClass::operator-(const instanceClass& sourcelist) 


( 


instanceNodePtrType newPrev, origCur; 
size = sourcelist.size; 
if ( sourcelist.head == NULL ) 
head = NULL; 
else { 
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head = new instanceNode; 
assert(head != NULL); 
head->item = sourcelist.head->iten; 


newPrev = head; 
for ( origCur = sourcelist.head->next; 
erigcur iz NULL; 
orrgCur — .origCur--nexEo ot 
newPrev->next = new instanceNode; 
assert (newPrev->next != NULL); 
newPrev = newPrev->next; 


newPrev->item = origCur->item; 


} 


newPrev->next = NULL; 


URS EI ER INN ER ENT I IE TI TE N ET TU N ER U U U I I I I SL U N KEN EI EI EN IH IE IT 


// displayInstanceList: Displays the list created * 
// LOCAL: int instancePosition - the position where to dispay node* 
ДИ timeType timeTemp - temp variable for time instance Z 
/4 int caimerosi tion - counter for time position in array* 
// Int success - true when node retrieved form list* 
IH. instance instanceTemp - the item to display * 


Ия EEE I IE RI I I Eu EI I KK IE I en EI u 


void instanceClass::displayInstanceList() 


{ 


instance instanceTemp; 
timeType timeTemp; 

Iintsimesbransetrssition = l; 
int timePosition - 0; 


int success; 


while (instancePosition <= ListLength()) 


{ 


ListRetrieve (instancePosition, instanceTemp, success); 
while (timePosition < instanceTemp.appCounter) 

Me = instanceTemp.timeArray[timePosition]; 

//1 added to timePosition because the array begins at zero 
cout««" T'«crymePosTtion 91e е; 
cout<<"sec=> "<<61шеТетр.СуУ зес<<", пвес => "; 


cout««timeTemp.tv usec««endl; 


timePositiontt; 
}//while 
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timePosition + 0; 
instancePosition++; 


)//while 
)//end 
ААА ЕЕ ОИУУ и 
// instanceComplete: Determines if all time positions in array are Р 
ДИ filled * 
// RETURN: pathLength--number of applications found in current instance* 
2 int success ~ true when node retrieved form list * 


SR АУУ + 


int instanceClass::instanceComplete(int pathLength, instance 
currentInstance) 


( 


return (pathLength == currentInstance.appCounter); 
} 


(e PATHTIMER MODULE 


хал а ата E UE WEITET ENTE TEE TE Ака ж 


// FILE: pathTimer.cpp * 
1I * 
// AUTHOR: Kendal Polk * 
// * 
// LAST MODIFIED: 6 June 2000 E 
n * 
// PURPOSE: This is the source file for operations necessary for the* 
7 pathTimer Module * 
r4 ж 
ml * 


Jf kc kk kk X kk ok X ok kal sk koe ke koe Sk ke К КК К Ж Ж RAR AAA LAA RARA NAAA AAA RA AAA 


"inciudespsrtumimer.nh" 


I np DLE LC жк Кок к к Ж ЖК е Че ЕК ЖОК ОКУ КК К КУС ЕК Ж К Жс Ж кк КК ke ke eoe eo 


77 cabepouestPashTime:; Based on currenti palh instance calculates the 


ДИ total path time (TPT) ші 
тИ * 
// INPUT: instance currentInstance * 
// int lastAppPosition * 
2 x 
// LOCAL: timetype firstAppTime * 
ДИ lastAppTime * 
пи returnApp $ 
Ил 5 
/£ RETURN TPIe ZeerurnApp) Б 
// X 

* 


Аян 


timeType calcTotalPathTime (instance currentInstance) 


{ 
timeType firstAppTime, lastAppTime, returnApp; 
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lar lastapprositión, 


lastAppPosition = currentInstance.appCounter - 1; 


firstAppTime = currentInstance.timeArray[0]; 


lastAppTime = currentInstance.timeArray[lastAppPosition]; 


гесаш ереси вес = Па-ссАрр оше сл зес Zrirstzoplimertvu eo, 
returnApp-tv изес- (lastApplime ву Бест лесе ЕЕ 


//correct for a negative fraction of second 
if (returnApp.tv_usec < 0){ 


if(returnApp.tv sec >= 0) { 
с ва ewe Ce l= — sale, 
ео рр во Пе: 
} 
else{ 
Der len2pp.Lvalsce к=; 
}//end if-else 

} 

Әсе ж ос seck poy 
ВЕНЕ += IE 
геросиерр Емш сес = 1000000 ЕЕ о usec; 

ЕЕ 


гетигп (гетигпАрр); 
)// end 


D. EVALUATE AND ALERT MODULE 


f[ kk Ж КК he ehe e He Je Je e He e he Je Je Fe ehe Je Je Je e e Je He e He de ese ee e ehe e e ehe ehe e de he ee he ee ee e e heck 


// FILE: evalalert.cpp * 
[| * 
// AUTHOR: Kendal Polk as a modification of Template from Data S 
fel, Abstraction and Problem solving with C++ by Frank * 
72 Carrano, CHA,ppl65: * 
ДА * 
// LAST MODIFIED: 6 June 2000 E 
А Б 
// PURPOSE: This is the source file for operations necessary for the* 
I evalalert Module * 
7 ж 
1 Е 


ff ck kk kk КА са У 


#include "evalalert.h" 
#include "pathDBInstance.h" 
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о ххх" ON 


// goodInstance: Based on totalpathtime(TPT) and path deadline, this* 


/ / 
/1 
n 


КО 


Ln 
7 
// 


КА а BEER A AR AA AER AR RT de ee 


function returns true if TPT <= deadline 


INPUT:  timetype totalPathTime 


deadline 


RETURN: 1 for true and O for false 


int goodInstance(timeType totalPathTime,timeType deadline) 


( 


зпеи сова = 0; 


cout««totalPathTime.tv sec««" TPT  "««deadline.tv sec««" DL 
secs\n"; 

cout<<totalPathTime.tv_usec<<" TPT "<<deadline.tv_usec<<" DL 
secs\n"; 


if(totalPathTime.tv sec » deadline.tv. sec)( 


good =g, 
} 
else 
if((totalPathTime.tv sec -- deadline.tv. sec)&& 
(totalPathTime.tv usec » deadline.tv usec))( 
good=0; 
)//if-else 


return (good); 
)//end 


* 


* 
* 
* 
* 
* 
* 
* 


ула а ааа а атта аа EDU UK kN eo ok ook ooo e eo eoe oe e e e e ek ЭЖ 


// evaluate : Based on false result from goodInstance rasies flag 


id 


// INPUT: timetype totalPathTime 


// 


deadline 


* 


* 


* 


* 


ля А 


void evaluate(timeType deadline, timeType totalPathTime) 


( 


#ifdef TPMS_DEBUG 


cout<<" I am here in evalalert\n"; 


#endif 


//lets see if this is a good instance 
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DO манаа уна 


if (!goodInstance(totalPathTime,deadline)) 
( 


raiseFlag(); 
}//end if 
}//end 


Кж EA ЕИ лаки 


// raiseFlag : This function emulates the identification of path not * 
ДИ meeting its defined dealine. Actions derived from this* 


727 келе спасторісі Бе defined in later work. * 
/ИХХХХЕХХХХХХХХХХХХХХХХХХХХХХХХЕХХЕХХХХХЕХХХХХХХЕХХХХХХХХХ ХХХ КАК ХХХ 


void raiseFlag() 

( 
cout<<"\n Flag Raised Mn"; 
//Should be developed later; 


}//end 


E. CONTROL MODULE 


J * ХКК КАК А АЖ қ Ж АА АЗАТ АСА ЖАККА жокка та а Ж ж ЭС ЗО СЭС 


27 PILE: tpms cpp * 
77 * 
// AUTHOR: Kendal Polk * 
ДИ Я 
// LAST MODIFIED: 21 June 2000 Ж 
d 5 
// PURPOSE: This is the entry point for "wrapped" applications to * 
/ / report their start and completion within their respective* 
ИА paths. This file represents the control module in the = 
77 TPMS architecture. + 
Ди d 


ду ххх E 


#include "specDB.h" 
#include <stddef .h> 
#include "pathDB.h" 
#include <sys/types.h> 
#include<sys/socket.h> 
#include <netinet/in.h> 
#include <netdb.h> 
#include <stdio.h> 
#include <errno.h> 
#include <time.h> 
#define BUFLEN 14 
//#define TPMS_DEBUG //uncomment here to receive debug statements 
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char appStatus; 


int maınlint arge, char* argv[]) 

{ 

SpecDBClass specDBList; 
pathDBClass pathDBList; 

//make the spec Database 
specDBList.createSpecDB(argv[1]); 
specDBList.displayList(); 

//build the initial path Database 
pathDBList.createPathDB(specDBList); 


pathDBList.displayPathList(); 


//set up to receive input from "wrapped" applications 


struct timeval currentTime, 
*currentTimePtr = &currentTime; 


struct timezone timezone, 
*timeZonePtr - &timeZone; 


int sockMain, addrLength, msgLength; 

struct sockaddr. in servAddr, clientAddr; 

char buf[BUFLEN], *leftPtr, *timePtr; 

if ((sockMain=socket (AF_INET,SOCK_DGRAM, 0)) <0) 
{perror("could not get sockect.\n"); 
ех1 е | 1); 
} 


bzero((char*) &servAddr, sizeof(servAddr)); 


servAddr.sin family - АЕ ТМЕТ; 
ServAddr.sin addr.s addr -zhtonl(INADDR. ANY); 


//this port is hardcoded so that wrapped applications know 
// to send their QoS output 
servAcddr.ssmepont-50001; 


if (bind(sockMain, (struct sockaddr *)&servAddr, sizeof(servAddr) )<0) 


ЭЛ 


(реггот( Сап Е get ров ли"): 
ехе) · 


) 


addrLength = sizeof (servAddr) ; 
if (getsockname(sockMain, (struct sockaddr *)&servAddr, g&addrLength) ) 
{perror(" getsockname failed.\n"); 
Sa 
) 


printf("\nserver: port Number is $dWMn", ntohs(servAddr.sin port)); 


//This infinite loop listens on the specified socket for reports 
// from the Clients Libraries reporting from wrapped applications 


КОЕ ОН 


addrLength =sizeof (clientAddr); 
ЛЕН И рееко (buf, BUELEN))It 
Printi оо) 2 

if((msgLength -recvfrom(sockMain,buf, BUFLEN,O, 
(struct sockaddr *)&clientAddr, 
&addrLength) ) <0) 
{perror("bad client socket\n"); 
exit(1)9 
)//perror 


#ifdef TPMS DEBUG 
printf("\nserver: Client’s IP address is: $s  ", 
inet ntoa(clientAddr.sin addr)); 


printt('*oportusesd in", ntohssTlTentAdcdmsssNueport)). 
#endif 


//determine the event character 
appStatus = buf[0]; 


// determine the ID of the application 
applieationrD appID = &buf DE 


//get reporting time from host computer 
gettimeofday(currentTimePtr, timeZonePtr); 


pathDBList.addAppTime(appStatus, appID,currentTimePtr,specDBList); 
#ifdef TPMS_DEBUG 
pathDBList.displayPathList(); 
#епаз Ё 
FAROE 


return 0; 
D 
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